Re: long term planning
- From: Liviu Andronic <landronimirc@xxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Sat, 28 Sep 2013 17:49:49 +0200
On Sat, Sep 28, 2013 at 10:03 AM, <tpgww@xxxxxxxxxxx> wrote:
> 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.
> 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.
> * Port emelFM2 to some other suitable library ?
>
As noted above, porting to either EFL or Qt would likely mean a 2nd
rewrite of emel.
> 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
--
Users can unsubscribe from the list by sending email to
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by
logging into the web interface.
Other related posts:
