I don't mind helping you convert it to the E gadget. Just let me know if you want the help.

Came across this ticket - Now that NetworkManager has been implemented into enlightenment/gadgets/wireless.git ... OpenVPN theoretically is supported though not configurable from the gadget as of yet.

Just see that its broken again at this point. Haven't looked yet.

@raster this is broken again -- This is like the third time this has been fixed and then someone keeps always going back in and breaking it again. Hmmm.

Please post a patch for review here first so we can test before it is pushed.

And lets make sure we test a lot of other areas before moving ahead. Item ordering changed for a lot of reasons that were broke with genlist, not the least of which was how odd/even theme signals were being relayed due to broke ordering, so lets make sure everything is sane before pushing this behavior back.

https://git.enlightenment.org/core/efl.git/commit/?id=cf359629a529200b3b9e0accd2c45821dc64f60e

Haven't been able to reproduce or heard of anyone able to reproduce in months so marking fixed.

Can confirm that tree_focus_allow_set false is already being set on the ctxpopups on E's end and that this is indeed an EFL bug as we are not allowing or taking focus for the ctxpopups.

+1 for a meeting.

In T5938#113686, @DaveMDS wrote:

@zmike ah, you right, the test is failing now, sorry I didn't know there was a test for this.

But it's the test that is wrong, as it is checking the new "broken" behavior, should I update the test to reflect the correct/legacy behavior?

In T6768#113679, @indefini wrote:

In T6768#113676, @raster wrote:

Time based or released based road maps are not of interest to those responding, including raster

You have GOT TO BE KIDDING. Let me quote myself above:

so just having goals and moving in that direction with regular releases of what is in a good state to release at that time is about as good as it gets. This is how the Linux kernel works and it's the largest open source project out there.

That is TIME BASED RELEASES. @indefini is 100% right - you are just wanting to complain and not bother with help because you don't even bother to read what does not fit your narrative. At least have the decency to read what I have written before pointing fingers at me claiming something that is utterly untrue. If there is one way to piss me off it is to accuse me of things that are absolutely untrue and OBVIOUSLY untrue. It's the 2nd insult you've managed in just this ticket. I'm beginning to think the problems in this project are people like you creating trouble where there is none. Yes. I'm calling you out on this.

I think he meant release roadmaps (time based or released based roadmaps) compared to this project roadmap that this ticket is about. I think he might be more interested about those than this project one.
And he says that you don't seem interested in release roadmaps because you wrote in the original ticket that you wouldn't gor for a per release roadmap.
I don't think he wants to tell lies :) this is just some misunderstanding :)

In T5938#113668, @DaveMDS wrote:

I restored the old behaviour with commit rEFLf0a0da9f449b

I think this only apply to legacy genlists and I hope I have not broken something else...
let me know if my commit broke something for you. It fix epymc for me :)

In T6768#113627, @indefini wrote:

In T6768#113626, @stephenmhouston wrote:

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

I think we have plenty of people willing to spend their time on management.

Then where are they? why did they not subscribed to this ticket and said "I want to do it, I want to maintain this project roadmap".

That isn't the problem. It seems to me the problem is no one wants to be managed/no one can agree on what should be managed/no one can agree on how it should be managed ... so in the end the plan is lets just make things up as we go - or depend on whatever raster says.

Yes, there is a problem on what should be and how it should be managed. That is why we opened this ticket to discuss about it!
We already identified some parts of the problem, now let's find/work on solutions.
I think you have to realize at one point that you are still in complaining mode. You have to switch to helping mode now.

In T6768#113586, @indefini wrote:

In T6768#113585, @raster wrote:

• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.

Technically this is what enventor does. It does require you "Save". It could just auto "save" and rebuild after every change (and if there is no error) update. Right now it's manual to save. Or were you more thinking of something that can monitor a set of files you edit in a text editor anywhere and do a rebuild and update a preview so it'd work with any editor?

I want to see the changes in real time without latency. I change some value in the edc text and it instantly updates, or I could click an object and resize it, set its offsets directly in the preview with the mouse and the text would update.
I think it would make the flow easier and faster. Saving and compiling is too slow imho.

• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.

Doing the library is really hard without also basically making policy. Also keeping compatibility. I think we have enough work doing that for EFL. I do totally agree with the touch/tablet support. I did start some work on that with a new vkbd module... It works decently in X. It does some touch support for a regular "Desktop" mode. Indeed proper mobile "fullscreen always" modes would be better still. I'm with you on this bit.

If it's too much work, it could be low priority. But if you want efl/enlightenment on any device I think it's not a bad idea to separate the common code into a library. The tizen watch wm must be quite different than e desktop, isn't it?

> At any rate. I appreciate the work you are doing -- and I know you would like to do more as many would -- but that you are struggling to get people to agree that what's failing the project is the continued unstructured philosophy, and if this is the best we can do with structure, then clearly it isn't good enough.
I agree. I think most people are not interested in management and can endure the problems that comes with no structure.

Ummm... I'm confused. It sounds like you disagree, but you say you agree... What exactly did you agree with?

I think I agreed with the struggling part. You said it too, it is disappointing to not see much activity on these tickets. Though it is understandable that developers don't want to spend their (free) time on management.
In the end maybe it's ok if just a few people make decisions about this?

ah you aren't using a tree.

In otherwords I don't think that item_)next/previous should delve into subitems at all... I think it should stay on the same level (as it does) and you can then delve into subitems with subitems_get

In T5938#113602, @DaveMDS wrote:

maybe I wrote the graph wrong, as your last comment seems non-sensical to me, I try again:

item #1
GROUP #1
 - item #2 
 - item #3
GROUP #2
 - item #4

in this scenario item_next(GROUP #1) currently return GROUP #2, while I expect (as is returned in 1.20) to return Item #2
... for sure not item #4

In T6768#113251, @indefini wrote:

In T6768#112939, @raster wrote:

first - thanks for documenting this and writing it up.

interesting. zero activity on this... nothing to say from anyone?

Maybe most people want a roadmap, but they don't feel the need to participate to it?
or they might propose changes to it later?

Here's what I want :)

• elementary : the possibility to make your own widgets easily and possibly share them.
• edc/themes : change edc and see the changes in real time, grammar/rules for edc/themes.
• engine : more opengl/vulkan api support, opengl win engine.
• enlightenment : a library to make your own wm, more touchscreen/tablet/phone support.
• less bugs :)

In T6768#113249, @stephenmhouston wrote:

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

I think you should write more precisely what you want this roadmap to be.
The first part about project vision is exactly what you said, but the rest is more like goals (and not "about us/philosophy") discussed by raster.
This is an overall project roadmap. Imho, it's not particularly made for releases and work but more for seeing where the project wants to go.
I discussed about a roadmap/ticket for each release in the original ticket T6740.

This is good for an About Us or Philosophy section on a website, but as far as releases and work goes, it doesn't even scratch the surface of what is needed for a roadmap.

The flat theme now reflects gadget bar (formerly bryce) and the new gadgets.

https://git.enlightenment.org/core/efl.git/commit?id=978a3db7f9ef3f9e53fe086a45b3620421d3edcd

I do have a concern with shelves and gadget bars (formerly bryce) ... the 6 pixel indicator on pager/ibar/ibox/luncher is a bit large... looks quite good at 4 pix or so for me. Thoughts?

https://git.enlightenment.org/core/efl.git/commit?id=dc676fec0a747d1a67d91f457e063dbfd20f6e59

I'm on board and working on the theme now. THIS is what we were missing. Great plan. I only have a few comments.

@raster can you create a workboard here on phab for the default theme, lets assume its going to be flat that you've been working on, and create tickets/tasks for everything that needs to be done to complete it - and to complete it having both light and dark styles? Then the rest of us can start pitching in and helping to try and get something done.

For the record - I would be all on board with taking a flat theme and offering it in light and dark versions. That would appease everyone and I agree with you on that being a solid solution.

Enlightenment.org is read like a book obviously and not scanned so if that is the argument you are going to make then it fits your argument to have a light background and dark text. By the way, regardless of contrast minimums now met, Enlightenment.org looks horrible. I mean it is truly bad. Anyhow...

Keep trying to replicate and give me more info/steps as to what you are doing to cause this. Perhaps valgrind a while and see if you can replicate it.

Fixed by: 6d6582e88916a76d479b73a01d65475d26678cbc

Fixed by: 6d6582e88916a76d479b73a01d65475d26678cbc

so basically for some odd reason, parents such as windows of objects with focus are getting focus out signals? that doesn't seem to be good.

I also suggested to you that you file this ticket to efl, which it is an efl bug unless you have a trace to prove otherwise, and I know there are genlist changes and fixes according to several efl devs. I suggested you change it from enlightenment to efl and assign it to @bu5hm4n intead of @zmike and you told me to do it like it was my ticket or something.

It has been fixed since then so try updating efl again.

did you update your efl?

This does seem to have been resolved within the last week. Any idea which commit fixed it?

How did you build Ephoto? With MESON? These are defines that should be included with config.h created by compiler.

I'm going to tag @cedric here and @q66 because I know they both mentioned to me they had their own ideas about how the sandbox gadgets can utilize languages other than C.

Just updated my EFL for the first time in a week or so and still get the crash but I will post the new bt in case line numbers or anything changed:

In T6625#109865, @DaveMDS wrote:

Sorry, but I really have no idea how the same performance and easy-of-use of edgar can be obtained with the sandbox infra.

This is also the reason why I'm not taking sandboxed stuff into serious consideration for the moment.

My plans is to port edgar to use the new bryce API as soon as bryce will provide all the features of the "shelve" system. Note that this port will be really easy for me to implement and will require zero (or near zero) modifications at the existing python gadgets.

Well Edgar doesn't apply to sandboxed gadgets @DaveMDS so we are more interested in hearing how something similar can work for that case. I.E. Explain what edgar does, can it be converted to sandboxed gadgets, if not, how we can do something similar, etc...

One idea I've had is going to be similar to how the sandboxed sysinfo gadgets work ... If they run by themselves they use the main loop, but they also have a separate function to create the gadget if they are run by the parent sysinfo gadget. This separate function could also be something that can be called as an event when E already realizes a process exists for a like minded gadget and would rather reuse that gadget process to create a new version than create a new process. The idea here being that Similar gadgets don't use multiple processes.

In T6443#109182, @zmike wrote:

This is a combination of bugs. The gadget must delete the child window as soon as the window is unfocused, as in the reference gadget https://git.enlightenment.org/enlightenment/modules/desksanity.git/tree/loader/test.c#n19. The docs should probably make this clear if it isn't already stated somewhere.

@zmike the artifacts were prominent at the time with wiked iirc. @bu5hm4n ?

In T6443#109155, @jf_simon wrote:

try this please.

Add slideshow gadget to desktop
open settings and click immediately outside the settings to dismiss
if the fileselector is still loading files, the popup is dismissed, but artifacts are left on desktop

if you wait until the fileselector is finished, all works fine

hope it helps.

Are you up to date? Line 881 for me is just a {

reeks of efreet as do a few other weird tickets out there, can't remember if they were irc, ml, or on phab, that seem to have the same behavior relating back to efreet.

@ajwillia.ms manages the docs and those pages these days
@stefan_schmidt manages Jenkins.

This reeks of efreet or something of the like.

What. This just started happening?

I don't see this on linux. @netstar Can you take a look at this and see if it is related your bsd code for this?

Again. This happens when you minimize and then restore windows? I need more details

This happens when you minimize a window and then restore it?

If I take screenshots, it freezes E and has to be killed almost every time. I will try to get more info. When it doesn't freeze I just get a black screenshot. I will say moving windows around or opening or closing menus, or something that forces draws seems to make it work *sometimes*

Fixed by: https://git.enlightenment.org/apps/ephoto.git/commit/?id=ad24a5a203acf97b67e122afd95786afa383656e

This should be fixed now, thank you for the report!

Maybe... but there is a timer there that gives plenty of time to get your cursor into the preview... if you just hang out in the open space...