Re: [E-devel] Systray - Ideas for a new spec

2008-03-10 Thread Toma
Well, Ive put the old spec you made raster on the wiki (dug up from
mailing list archives from 2006!) so everyone can see and discuss it
further. Sure would be nice if you could look over it and change
anything. Id like to attach it to the SoC idea about the systray, so
that if it does get in, then we can produce a working example for the
xdg folks to look at. Itll also need some applications that actually
use it, so if anyone wants to include some systray code in anything,
that too would be cool.
Toma

On 10/03/2008, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote:
> On Mon, 10 Mar 2008 13:33:21 +0900 Toma <[EMAIL PROTECTED]> babbled:
>
>
>  > Heres whats happened so far!
>  > http://lists.freedesktop.org/archives/xdg/2008-March/009303.html
>  >
>  > Here are some of the summaries from people...
>  > "yeah, i'd really like to see this happen too. it requires someone to write
>  > the spec and start with implementations ... we've sort of all been staring 
> at
>  > each other for a few years now waiting for someone to have the time and
>  > energy to do it. "
>  > -A Seigo (KDE Developer)
>  >
>  > "It doesn't make sense to try to write a new
>  > spec without having at least a proof-of-concept implementation. I hate the
>  > current systray too, and I have somewhere an unfinished attempt at a better
>  > implementation, but it's in the queue with many other things. Saying how 
> the
>  > systray needs fixing is unfortunately not going to do that, somebody needs 
> to
>  > find the time to make it happen."
>  > -L Lunak (KDE developer)
>  >
>  > No news from anyone in the Gnome camp yet, but I get the impression
>  > that everyone, including some people in the E camp that hate the
>  > notion of having a systray at all.
>  > Feel free to read the archive so far and/or join in the systray
>  > bashing on the mailing list there.
>  > Toma
>
>
> it was the gnome camp last time that poo-pooed any changes to systray. seigo
>  was all for improving/fixing the spec. i sent changes to the spec to the 
> list a
>  full description of the ideas, but nothing happened. i always intended to
>  actually implement these changes.
>
>
>  > On 05/03/2008, Toma <[EMAIL PROTECTED]> wrote:
>  > > Great.
>  > >  Heres the spec in question if anyone wants to read and add anything.
>  > >  
> http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html
>  > >
>  > >  Also this interesting little article.
>  > >  http://www.xvsxp.com/interface/menuextrastray.php
>  > >
>  > >
>  > >  Toma
>  > >
>  > >
>  > >
>  > >  On 05/03/2008, The Rasterman Carsten Haitzler <[EMAIL PROTECTED]> wrote:
>  > >  > On Tue, 4 Mar 2008 23:59:44 +0900 Toma <[EMAIL PROTECTED]> babbled:
>  > >  >
>  > >  >
>  > >  >  > Im trying to get some chatter about a new systray spec on the
>  > >  >  > freedesktop.org mailing list.
>  > >  >  > Since Im no programmer myself, I would like to try to just solidify
>  > >  >  > some points that you all have and then put them all together and 
> mail
>  > >  >  > it into them.
>  > >  >  > I figure the problem wont fix itself and some of you have some good
>  > >  >  > ideas for it.
>  > >  >  > Lets make some noise about this while KDE4 is fresh and see if any
>  > >  >  > collaboration in that respect can happen.
>  > >  >  > Toma
>  > >  >
>  > >  >
>  > >  > well i've made them before on the wm spec list, so here goes:
>  > >  >
>  > >  >  1. systray "icon" windows are all implemented as solid windows. they
>  > >  > are a hack around using icon windows in good old ICCCM but no better
>  > >  > functionally - just much more obfuscated with all the selection
>  > >  > mechanism stuff. as such they suffer the problems of icon windows:
>  > >  >  1.1 can only have 1 copy of them on screen in 1 place. doesn't allow 
> a
>  > >  > tray to duplicate visual copies of them or functional ones.
>  > >  >  1.2 they are windows - the implementations all assume that a tray 
> will
>  > >  > be in the same toolkit as the app (gtk just creates little grey box
>  > >  > windows, kde/qt assume copyfromparent is a good idea for the 
> background
>  > >  > - which is a bad assumption). as such the spec discourages good
>  > >  > implementation. 1.3 the spec should use the NETWM_ICON property to
>  > >  > deliver an ARGB image to display. the tray can scale, draw, composite 
> or
>  > >  > whatever it wants. it can no create multiple copies. if the icon needs
>  > >  > to change - a property change will do the job. doing more is probably
>  > >  > abusing systray icons far beyond what they should be used for.
>  > >  >  1.4 as such systray icons have just become a way for apps to avoid
>  > >  > showing a main window but stay running. they function often simply as 
> a
>  > >  > replacement for iconification in icccm. thus using the same mechanism 
> is
>  > >  > the better way to go.
>  > >  >
>  > >  >  2. as such icons want some form of interaction with users - do be 
> able
>  > >  > to click on them to act

Re: [E-devel] Systray - Ideas for a new spec

2008-03-10 Thread lok
Hi,

I took time to talk to this subject because I wanted to write my proof 
of concept before replying. In my opinion, a systray is a bad idea. For 
the last two weeks I kept asking myself, "Why do people want a systray ? 
What exactly is a systray ? How can I provide it ?".  For the first  
question I've directly asked to anybody I know was using trayer, or 
wanted a tray on E. The answers were about having a way to be notified, 
a quick way to show/hide some windows. A few were about using direct 
actions and each time with the same example, an audio player. And the 
last one that nobody say directly but somehow is always there, because 
they are simply used to it.

For the second question, the easiest way to find out what exactly is a 
systray, it's to look at the source. A systray on windows is the only 
way to move an app outside the taskbar, the only way to keep visible an 
application running in the background but needs a GUI sometimes and was 
the only way to provide a pseudo gadget. Nowadays a huge amout of 
applications running on windows put something in the tray. Most of the 
time the systray have more applications than the taskbar, and 3/4 of 
them being hidden to take less place within the bar (so much for the 
monitoring). So what exactly is a systray ? I dunno, if it's a way to 
continuously notify why hide the icons and show a bubble ? If it's a way 
to lighten the taskbar why only the application as the power to choose ? 
And if it's a way to provide quick actions why do we still need this 
under our WMs were any one of them can use modules for years ?

Well, here is the problem. A systray is a mess in it's basic design. 
Some half done thing wishing to compete with OS X dock. So write a spec, 
even good, about something doing a bit of (continuous ?) notification, a 
bit of quick action and a bit of docking isn't, in my opinion, the 
greatest thing to do. Of course it will works, but why redo half of the 
job instead of finishing it once and for all ?

First let's have a _real_ fdo specification about notifications, 
galago's one was refused. It still miss some details, but I think it's a 
good base. And I believe it's something far more useful than just a 
common way to blink an icon somewhere in the screen (the urgent flag can 
already be used to do it). By pushing it a little I did the notification 
boxes :
http://lok.eadrax.org/images/notification_box-3.png
http://lok.eadrax.org/images/notification_box-4.png
Which means than a good notification spec could cover all the aspect of 
notifications, popups and icons. Moreover I didn't implemented it but 
this spec handle actions, their purpose is to reply to an event.

A docking specification doesn't seems necessary, we already have 
everything we need to dock an application like it would be in a tray. 
IIirk is the proof and IBox is also a solution.

And finally for quick actions there is no common way possible. Depending 
on the purpose of the applications you will not wish to display it the 
same way. For an audio player, having a module giving you the 
possibility to play/pause/next/prev with a single click is better than 
openning a menu and choosing the good action in it. See 
http://www.kuliniewicz.org/music-applet/ for example. Whereas to quickly 
change a network like with network-manager you would rather have a popup 
with a list showing directly the name of the network, if it's protected 
and how good you catch it. All that using the same look than your WM. 
Redoing a module for each WM takes more work but end up nicer than 
reducing everything to a menu.

Mixing iiirk and notification together would provide over 90% of what a 
tray does. Add to that IBar/IBox and you get something near OS X dock. 
Of course any other combination is possible. All this relying only on 
the .desktop spec, a notification one and the old NetWM's skip flags, 
breaking nothing and just requiring sometimes to install a notification 
plugin.

So no I don't think we should change the tray spec, we should forget 
about it. Even if we do change it, even if we also manage to make the 
applications following the new one. All we will get is a bunch of icons 
stacked at their own will in a corner with the ability to open a menu. I 
would rather like to see a clean and complete notification spec accepted 
by FDO.

Samuel 'lok' Mendes

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Nightly build log for E17 on 2008-03-10 07:09:14 -0700

2008-03-10 Thread Nightly build system
Build log for Enlightenment DR 0.17 on 2008-03-10 07:09:14 -0700
Build logs are available at http://download.enlightenment.org/tests/logs

Packages that failed to build:
ecore_li  http://download.enlightenment.org/tests/logs/ecore_li.log
engage  http://download.enlightenment.org/tests/logs/engage.log
enna  http://download.enlightenment.org/tests/logs/enna.log
epdf  http://download.enlightenment.org/tests/logs/epdf.log

Packages with no supported build system:
entice, esmart_rsvg, exorcist, python-efl, 

Packages skipped:
camE, enotes, enscribe, epbb, eplay, erss, etk_server, etox, e_utils, 
Evas_Perl, 
evoak, gfx_routines, lvs-gui, med, nexus, notgame, ruby-efl, webcam, 

Packages that build OK:
alarm, bling, calendar, cpu, deskshow, echo, eclair, ecore, edata, edb, 
e_dbus, edje_editor, edje, edje_viewer, edvi, eet, eflame, eflpp, efm_nav, 
efm_path, efreet, elapse, elation, elicit, elitaire, e, embrace, embryo, 
emotion, emphasis, empower, emprint, emu, enesim, engrave, engycad, enhance, 
enity, enterminus, enthrall, entrance_edit_gui, entrance, entropy, envision, 
epeg, ephoto, e_phys, epsilon, epx, equate, esmart, estickies, etk_extra, 
etk, etk-perl, evas, evfs, evolve, ewl, examine, execwatch, exhibit, exml, 
expedite, express, exquisite, extrackt, feh, flame, forecasts, gevas2, iconbar, 
imlib2_loaders, imlib2, Imlib2_Perl, imlib2_tools, language, mail, mem, 
mixer, moon, mpdule, net, news, notification, penguins, pesh, photo, rage, 
rain, screenshot, scrot, slideshow, snow, taskbar, tclock, uptime, weather, 
winselector, wlan, 

Debian GNU/Linux 4.0 \n \l

Linux enlightenment2 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 
GNU/Linux


See http://download.enlightenment.org/tests/ for details.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] Ecore_Con_Url patch

2008-03-10 Thread Lars Munch
On Mon, Mar 10, 2008 at 03:43:04AM +1100, Carsten Haitzler wrote:
> On Fri, 7 Mar 2008 15:30:07 +0100 "Cedric BAIL" <[EMAIL PROTECTED]> babbled:
> 
> > As I previously discussed, I did have some issue with evas_render not
> > being called when my computer receive data too fast. The problem was
> > the handling of the download prevented ecore to go into idle and call
> > evas_render.
> > 
> > To fix this, this patch change the way the fd handler is used. When
> > some curl data are received, I stop all curl fd handler and setup an
> > idle handler. This force ecore to go in idle mode and call evas_render
> > before reading pending data.
> > 
> > As ecore_file_download suffer the same problem and did want to
> > maintain two different user of curl library. I added a new interface
> > to ecore_con_url so that if it can directly write some data to any fd
> > and used this to reimplement ecore_file_download. This change should
> > not have a big impact on file download speed but the interface should
> > stay responsive what ever your computer and your download speed is !
> 
> in cvs :)

This patch seems to break linking againts libecore_file.so for me. I am
building ecore without curl support and after the latest changes in
ecore_file_download.c I get the following linking errors:

arm-iwmmx-linux-gnueabi/usr/lib/libecore_file.so: undefined reference to
`_ecore_file_download_abort'

To me it looks like the _ecore_file_download_abort function just needs 
to be moved out of the HAVE_CURL ifdef's.

Regards
Lars Munch


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


[E-devel] Problem with "Window Remember (Virtual Desktop)"

2008-03-10 Thread thomasg
Hey there,

I have a problem with the remember-window-settings, that is there since this
settings exists:
If I remember the settings "Virtual Desktop" or "Current Screen" it works
fine, but for starting the apps I need to have my focus/view on the screen
the app should start on.
This is a problem as you might forget that you turned on the
remember-settings some time ago and the application simple won't show up
when you start it, without an error.
Especially if you have really many vdesktops it can be a problem to come to
named desktop so you probably might look for an error where is none.

So my question is: Is there a way to start this applications in background
on the correct screen without viewing it? If not, would it at least be
possible to have a little signal that the app will appear when the focus is
on screen/vdesktop $x?
Furthermore, for the first case, it would be cool to have a little reminder
on which desktop the application started, I guess the pager-popup can do
that job.

As this could really improve the usability (and as I have this problem every
month without remembering what the reason was  :-) ) I'd be glad to get
answers or even better a solution.

Cheers,

thomasg
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Problem with "Window Remember (Virtual Desktop)"

2008-03-10 Thread Ravenlock
On 03/10/2008 14:00, thomasg wrote:
> Hey there,
> 
> I have a problem with the remember-window-settings, that is there since this
> settings exists:
> If I remember the settings "Virtual Desktop" or "Current Screen" it works
> fine, but for starting the apps I need to have my focus/view on the screen
> the app should start on.
> This is a problem as you might forget that you turned on the
> remember-settings some time ago and the application simple won't show up
> when you start it, without an error.

I've not tried in the last month... maybe two... but I seem to recall
this working for me without errors.

If anyone else can confirm this being an issue, I'll steal a monitor
from my office and fix'er up.

> Especially if you have really many vdesktops it can be a problem to come to
> named desktop so you probably might look for an error where is none.
> 
> So my question is: Is there a way to start this applications in background
> on the correct screen without viewing it? If not, would it at least be
> possible to have a little signal that the app will appear when the focus is
> on screen/vdesktop $x?
> Furthermore, for the first case, it would be cool to have a little reminder
> on which desktop the application started, I guess the pager-popup can do
> that job.
> 
> As this could really improve the usability (and as I have this problem every
> month without remembering what the reason was  :-) ) I'd be glad to get
> answers or even better a solution.
> 
> Cheers,
> 
> thomasg
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 


-- 
Regards,
Ravenlock




signature.asc
Description: OpenPGP digital signature
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Problem with "Window Remember (Virtual Desktop)"

2008-03-10 Thread thomasg
Well, I have to do a self-reply now:
Seems the problem is not longer existing - the e17 version on my laptop was
too old and it seems that it has been fixed some time ago. On my desktop it
works perfectly.
Consider the first mail as never written. :)
Sorry for the circumstances,

thomasg

On 3/10/08, thomasg <[EMAIL PROTECTED]> wrote:
>
> Hey there,
>
> I have a problem with the remember-window-settings, that is there since
> this settings exists:
> If I remember the settings "Virtual Desktop" or "Current Screen" it works
> fine, but for starting the apps I need to have my focus/view on the screen
> the app should start on.
> This is a problem as you might forget that you turned on the
> remember-settings some time ago and the application simple won't show up
> when you start it, without an error.
> Especially if you have really many vdesktops it can be a problem to come
> to named desktop so you probably might look for an error where is none.
>
> So my question is: Is there a way to start this applications in background
> on the correct screen without viewing it? If not, would it at least be
> possible to have a little signal that the app will appear when the focus is
> on screen/vdesktop $x?
> Furthermore, for the first case, it would be cool to have a little
> reminder on which desktop the application started, I guess the pager-popup
> can do that job.
>
> As this could really improve the usability (and as I have this problem
> every month without remembering what the reason was  :-) ) I'd be glad to
> get answers or even better a solution.
>
> Cheers,
>
> thomasg
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] EFL and Webkit

2008-03-10 Thread Jose Gonzalez
Carsten Haitzler (The Rasterman) wrote:
>
>>  Either way, this would allow for engine-specific extensions
>> for evas.. wrapping things adequately would allow for things like
>> say an "evas3D" lib if really desired.
>
> sure. 3d INSIDE a "3d object" i can deal with in evas :)
>

Exactly. Wrap things say a 3d-scene object and do your 3d stuff
'inside' such an object. One can do both immediate-mode and retained-
mode kinds of rendering to such a scene object. For the latter type,
one could have auxiliary 3d objects which must be 'bound' to such a
scene, with coordinates rel to the scene obj,... eg. a 3d-scene object
itself might be one such object that one could add to another, and
ideally all evas primitives would also be added to such a 3d-scene
object.
One can extend evas in various ways by suitably having such
objects which are like 'canvases' themselves that may support their
own kinds of rendering/object system... things like 3d, svg, html,
and many others are all possible in this way.


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] [PATCH] Ecore_Con_Url patch

2008-03-10 Thread The Rasterman
On Mon, 10 Mar 2008 17:28:55 +0100 [EMAIL PROTECTED] (Lars Munch) babbled:

fixed :)

> On Mon, Mar 10, 2008 at 03:43:04AM +1100, Carsten Haitzler wrote:
> > On Fri, 7 Mar 2008 15:30:07 +0100 "Cedric BAIL" <[EMAIL PROTECTED]>
> > babbled:
> > 
> > > As I previously discussed, I did have some issue with evas_render not
> > > being called when my computer receive data too fast. The problem was
> > > the handling of the download prevented ecore to go into idle and call
> > > evas_render.
> > > 
> > > To fix this, this patch change the way the fd handler is used. When
> > > some curl data are received, I stop all curl fd handler and setup an
> > > idle handler. This force ecore to go in idle mode and call evas_render
> > > before reading pending data.
> > > 
> > > As ecore_file_download suffer the same problem and did want to
> > > maintain two different user of curl library. I added a new interface
> > > to ecore_con_url so that if it can directly write some data to any fd
> > > and used this to reimplement ecore_file_download. This change should
> > > not have a big impact on file download speed but the interface should
> > > stay responsive what ever your computer and your download speed is !
> > 
> > in cvs :)
> 
> This patch seems to break linking againts libecore_file.so for me. I am
> building ecore without curl support and after the latest changes in
> ecore_file_download.c I get the following linking errors:
> 
> arm-iwmmx-linux-gnueabi/usr/lib/libecore_file.so: undefined reference to
> `_ecore_file_download_abort'
> 
> To me it looks like the _ecore_file_download_abort function just needs 
> to be moved out of the HAVE_CURL ifdef's.
> 
> Regards
> Lars Munch
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)[EMAIL PROTECTED]


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Systray - Ideas for a new spec

2008-03-10 Thread Jose Gonzalez

Samuel (lok) wrote:

 > Mixing iiirk and notification together would provide over 90%
 > of what a tray does. Add to that IBar/IBox and you get something
 > near OS X dock. Of course any other combination is possible.

What's an "iiirk"?


-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Systray - Ideas for a new spec

2008-03-10 Thread Toma
iiirk is a new module thats in E cvs. Its quite nifty.
Toma

On 11/03/2008, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>
> Samuel (lok) wrote:
>
>   > Mixing iiirk and notification together would provide over 90%
>   > of what a tray does. Add to that IBar/IBox and you get something
>   > near OS X dock. Of course any other combination is possible.
>
>
> What's an "iiirk"?
>
>
>
>  -
>  This SF.net email is sponsored by: Microsoft
>  Defy all challenges. Microsoft(R) Visual Studio 2008.
>  http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
>  ___
>  enlightenment-devel mailing list
>  enlightenment-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] Edje TEXT problems with ellipses calc

2008-03-10 Thread Sebastian Dransfeld
Gustavo Sverzut Barbieri wrote:
> Hi,
> 
> Just identified that
> 
>  part {
> name: "text";
> type: TEXT;
> description {
>state: "default" 0.0;
>rel2 {
>   relative: 0.0 1.0;
>   offset: 118 -1;
>}
>text {
>   font: "Vera Sans:style=Bold";
>   size: 20;
>   text: "Some text";
>}
> }
> 
> will cause Edje to mis calculate and return an empty string as result.
> Increasing or decreasing it by one pixel in width will make it "work"
> again, so it's a bit tricky to found in real world applications (but
> we did).
> 
> But trickier than finding this is to get the logic of
> _edje_text_fit_x()... maybe someone else is more familiar with it and
> can provide some insight? If not then I'll dig into it later.
> BTW, why these kind of constructions are not provided by Evas?
> Evas should provide these high level utilities, like how many of some
> given text will fit in given width, height or both (these last 2 in in
> case of textblock). Also, since adding ellipses are a common case, we
> could add it as well. Maybe we could also use this to speed up these
> calcs, since calling all those Evas functions from inside Edje can be
> a bit a hit in performance :-/

I hit a similar problem a while ago, and tried to fix it. The problem 
was that when you use shadows etc. the size evas reports for the string 
isn't the same size that evas uses for the resulting evas object. This 
might be a similar thing.

I agree, more of the logic should be moved to evas as it isn't to easy 
to grok what object size a text string will result in.

Sebastian

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel