long term planning

[t***@onepost.net]

Hello all. Like to share some thoughts.

You might know that I always try to release code that avoids deprecated elements of the latest non-development releases of glib and gtk/gdk. As gtk3 progresses, this policy is becoming increasingly problematic, and as from 3.6, practically impossible. Sooner or later (gtk4?), the deprecated elements will go completely, and we're stuck.

What to do?

* Ignore the problem, and assume gtk3 (or gtk2) will always be around ?
* Pressure gtk devs to fix at least some of their issues ?
* Encourage some team to 'do a cinnamon' on gtk3 ?
* Dumb-down emelFM2 so that it can cope with gtk4 ?
* Port emelFM2 to some other suitable library ?
* Something else ?

I have no firm views about which way to go. I'd welcome some discussion about this.

As I look into the newly-released gtk 3.10, I'm coming to agree with the opinion I've seen around the place, to the effect that libgtk3 is on its way to becoming libgnome3. Meaning not a reasonable level of support for independent applications.

In this latest episode, support for internal/stock icons goes. So, no more menu-items or buttons that include icons, just plain labels for those. No more entries with embedded stock icons. And so on. I look forward to DnD operations where we see the drag accompanied by a label instead of an icon! Or else long suffering theme maintainers will each need to add a bundle of extra icons, and someone needs to invent an API to map back and forth between icon name and corresponding label.

Another example this time is removal of the UI manager, which is used (though not by e2) to describe/define an application's UI layout. Of course! Why didn't we think of this before? What reasonable developer would want/need to design his/her own UI? :-)

In gtk 3.6 documentation, it was announced that what I'll call the 'display-locking API' is to go. Some such arrangement is needed because display-server interfaces (xlib, we're looking at you) hate concurrent usage. Maybe wayland etc will be better. Anyway, in future, all use of gtk functionality is supposed to be in the main thread of an application. IMHO, this pretty much means that any non-trivial application needs to be single-threaded. I'd certainly agree that the current API is not good for a shared library, and glib at its heart is a kludge for threads, but those issues could be fixed, instead of walking away. Even I could do it (trivial changes to gtk itself, but fundamental changes to glib's mainloop). Then again, maybe gnome3 applications are intended to be simple or a bit slugg
ish. :-)

I've seen some comment to the effect that efl is not thread-safe. I know even less about other available libraries. Maybe there's an opportunity here, to plug this gap.

BTW, all this is quite independent of the un-fixable bad behaviour seen when running on recent gtk3, which I still suspect is theme-related.

Regards
Tom

[Arve Barsnes]

Post by t***@onepost.net
What to do?
* Ignore the problem, and assume gtk3 (or gtk2) will always be around ?
* Encourage some team to 'do a cinnamon' on gtk3 ?
* Port emelFM2 to some other suitable library ?

It seems to me increasingly obvious that the people behind gnome are going
crazy, so staying on gtk2 until that day when someone creates a usable fork
seems like the only workable option.

Arve

[Liviu Andronic]

Post by t***@onepost.net
Hello all. Like to share some thoughts.
You might know that I always try to release code that avoids deprecated elements of the latest non-development releases of glib and gtk/gdk. As gtk3 progresses, this policy is becoming increasingly problematic, and as from 3.6, practically impossible. Sooner or later (gtk4?), the deprecated elements will go completely, and we're stuck.

I once sounded the Gtk3 alarm bells wrt to Xfce:
http://mail.xfce.org/pipermail/xfce/2013-March/032049.html . The
position of one of the core devels was that "there was nothing wrong
with gtk3": http://mail.xfce.org/pipermail/xfce/2013-March/032057.html
. The idea of using EFL wasn't very appealing either, as it would mean
(yet another) rewrite of Xfce. I guess emelFM2 is in a very similar
position.

Post by t***@onepost.net
What to do?
* Ignore the problem, and assume gtk3 (or gtk2) will always be around ?
* Pressure gtk devs to fix at least some of their issues ?
* Encourage some team to 'do a cinnamon' on gtk3 ?
* Dumb-down emelFM2 so that it can cope with gtk4 ?

Definitely not. We shouldn't tie emel to a sinking ship. There is also
Qt and EFL already out there.

Post by t***@onepost.net
* Port emelFM2 to some other suitable library ?

As noted above, porting to either EFL or Qt would likely mean a 2nd
rewrite of emel.

Post by t***@onepost.net
I've seen some comment to the effect that efl is not thread-safe.

What do you mean by this? What practical issues does this pose for a
potential future rewrite in EFL?

Liviu

[t***@onepost.net]

On Sat, 28 Sep 2013 17:49:49 +0200

Post by Liviu Andronic

Post by t***@onepost.net
I've seen some comment to the effect that efl is not thread-safe.

What do you mean by this?

In efl's specific case, I can't be sure.

Typically this phrase means it's not safe for different threads to use the same functionality (usually, call the same function) at times which overlap. This is most likely due to potential or actual change of shared/common data. There are mechanisms to 'block' such overlaps, but they may not be implemented, or if they're used improperly, they can cause a freeze.

Sometimes there's a related problem, if the functionality is used recursively e.g. a function calls itself. This is easy to manage if the recursion is easy to spot, but code-paths can be quite complex, and hard to test/debug.

What practical issues does this pose for a

Post by Liviu Andronic
potential future rewrite in EFL?

All actions (core and plugins) are run in a separate thread (actually, one thread per actions-queue). Typically they involve some use of gtk.

All filelist updates are done in a separate thread. Those definitely use gtk.

If we're happy enough to abandon multi-threads, that might lead to a different choice of future strategy.

Regards
Tom

[t***@onepost.net]

On Sun, 29 Sep 2013 07:45:36 +1000

Post by t***@onepost.net
On Sat, 28 Sep 2013 17:49:49 +0200

Post by Liviu Andronic

Post by t***@onepost.net
I've seen some comment to the effect that efl is not thread-safe.

What do you mean by this?

In efl's specific case, I can't be sure.

Well, I can a bit, if I take time to read the original documentation ...

"The EFL is, for the most part, not thread safe. This means that if you have some task running in another thread and you have, for example, an Evas object to show the status progress of this task, you cannot update the object from within the thread. This can only be done from the main thread, the one running the main loop. This problem can be solved by running a thread that sends messages to the main one using an Ecore_Pipe, but when you need to handle other things like cancelling the thread, your code grows in complexity and gets much harder to maintain.

Ecore Thread is here to solve that problem."

So, at least they provide off-the-shelf solution.

Regards
Tom

[Geoff]

On Sat, 28 Sep 2013 18:03:38 +1000

Post by t***@onepost.net
Hello all. Like to share some thoughts.

<snip>

Is there a chance that your second or third and fourth options might work? They
don't sound like things emelfm2 users could achieve alone, but I would happily
write emails / sign petitions or do whatever other small thing I can to bring
about any of those outcomes. Porting to another library sounds attractive from
a user's perspective but sounds like a mountain of work for you. Ignoring the
problem is appealing in some ways, but projects that don't move forward tend to
die. I hate it, but dumbing down might be the most practical alternative.

Just musing a moment, when I came to linux in about the year 2000 I looked at
gnome and kde and wondered why I would bother changing from Windows just to get
a worse version of it. Then I learned that I could run all the applications I
wanted to under a wide range of window managers just by having the necessary
libraries and that allowed me to make the change. This gtk trend is a sad way
for that freedom to begin to end.

Geoff

[Charles A Edwards]

On Sat, 28 Sep 2013 18:03:38 +1000

Post by t***@onepost.net
You might know that I always try to release code that avoids
deprecated elements of the latest non-development releases of glib
and gtk/gdk. As gtk3 progresses, this policy is becoming increasingly
problematic, and as from 3.6, practically impossible. Sooner or later
(gtk4?), the deprecated elements will go completely, and we're stuck.
What to do?
* Ignore the problem, and assume gtk3 (or gtk2) will always be around ?
* Pressure gtk devs to fix at least some of their issues ?
* Encourage some team to 'do a cinnamon' on gtk3 ?
* Dumb-down emelFM2 so that it can cope with gtk4 ?
* Port emelFM2 to some other suitable library ?
* Something else ?

pcmanfm already has a Qt port and in the near feature it, as well as
lxde, Will switched to Qt.

They have set-up a wiki page detailing some of the issues migrating
from GTK+ to Qt

http://wiki.lxde.org/en/Migrate_from_GTK%2B_to_Qt


Charles
--
Murder is always a mistake -- one should never do anything one cannot
talk about after dinner.
-- Oscar Wilde, "The Picture of Dorian Gray"
----------------------
Mageia release 4 (Cauldron) for x86_64$
On SuperSize....http://www.eslrahc.com
Registered Linux user #182463
3.11.2-server-1.mga4 x86_64
----------------------

[t***@onepost.net]

On Sun, 29 Sep 2013 18:52:19 -0400

Post by Charles A Edwards
pcmanfm already has a Qt port and in the near feature it, as well as
lxde, Will switched to Qt.
They have set-up a wiki page detailing some of the issues migrating
from GTK+ to Qt
http://wiki.lxde.org/en/Migrate_from_GTK%2B_to_Qt

Thanks Charles. Very valuable resource, in our present context.

Looking through the information, I see too many things relevant to emelFM2 that are N/A. So I guess that qt is off the table.

In recent days I've taken a look at efl. No surprise, it's strongly aligned to images. I was a bit surprised to see how weak it is on text. Elementary has no textview, though the deprecated EWL did, I think. No font management. Maybe we use clumsy embedded HTML-like markup, or maybe its practically impossible, to do colored text (as distinct from colored effects around text). Not enough data provided about the notebook-equivalent, to know whether it can show tabs on either side.

So it looks to be easier to get to efl than to qt, but still quite hard.

Regards
Tom

[ccpaging]

Is it possible to make a single windows to manage copying and moving task?

Those work always cost long time.

Post by t***@onepost.net
On Sun, 29 Sep 2013 18:52:19 -0400

Post by Charles A Edwards
pcmanfm already has a Qt port and in the near feature it, as well as
lxde, Will switched to Qt.
They have set-up a wiki page detailing some of the issues migrating
from GTK+ to Qt
http://wiki.lxde.org/en/Migrate_from_GTK%2B_to_Qt

Thanks Charles. Very valuable resource, in our present context.
Looking through the information, I see too many things relevant to emelFM2
that are N/A. So I guess that qt is off the table.
In recent days I've taken a look at efl. No surprise, it's strongly
aligned to images. I was a bit surprised to see how weak it is on text.
Elementary has no textview, though the deprecated EWL did, I think. No font
management. Maybe we use clumsy embedded HTML-like markup, or maybe its
practically impossible, to do colored text (as distinct from colored
effects around text). Not enough data provided about the
notebook-equivalent, to know whether it can show tabs on either side.
So it looks to be easier to get to efl than to qt, but still quite hard.
Regards
Tom
--
Users can unsubscribe from the list by sending email to
by logging into the web interface.

[t***@onepost.net]

On Sat, 5 Oct 2013 18:02:42 +0800

Post by ccpaging
Is it possible to make a single windows to manage copying and moving task?
Those work always cost long time.

Do you mean for processing big files, that take a long time to copy or move?

If so, have you tried the copy and move plugins? They show a progress dialog in a separate window.

Other than that, it's only one filelist to the other.

Regards
Tom

[ccpaging]

Post by t***@onepost.net
On Sat, 5 Oct 2013 18:02:42 +0800

Post by ccpaging
Is it possible to make a single windows to manage copying and moving task?
Those work always cost long time.

Do you mean for processing big files, that take a long time to copy or move?
If so, have you tried the copy and move plugins? They show a progress dialog in a separate window.
Other than that, it's only one filelist to the other.
Regards
Tom

Yes. The copy pulgin really help.

May I want more? For example, pause/resume even cancel copying and
waitting, calc space etc.

[t***@onepost.net]

On Tue, 08 Oct 2013 18:10:22 +0800

Post by ccpaging

Post by t***@onepost.net
On Sat, 5 Oct 2013 18:02:42 +0800

Post by ccpaging
Is it possible to make a single windows to manage copying and moving task?
Those work always cost long time.

Do you mean for processing big files, that take a long time to copy or move?
If so, have you tried the copy and move plugins? They show a progress dialog in a separate window.
Other than that, it's only one filelist to the other.
Regards
Tom

Yes. The copy pulgin really help.
May I want more? For example, pause/resume even cancel copying and
waitting,

Those plugins can do these things. (Or at least, they're supposed to, I personally haven't tested this capability for a long time.)

Post by ccpaging
calc space etc.

One of the default 'user commands' in the filelist context menu does this, using shell commands stat and awk.

Regards
Tom