Klaus 'mrmoku' Kurzmann schrieb:
Hey all,
I have problems building ewl. It fails with missing po/Makefile.in.in.
Am I doing something wrong here?
configure: creating ./config.status
config.status: creating Makefile
config.status: creating ewl.spec
config.status: creating ewl.pc
2008/12/24 Peter Wehrfritz peter.wehrfr...@web.de:
Peter Wehrfritz schrieb:
4 pixels sound like inset or padding pixels. Since the size request
happens before the realization some pixels for the inset will be added
later, when the theme data is loaded. I think for the framebuffer, unlike to
Peter Wehrfritz schrieb:
4 pixels sound like inset or padding pixels. Since the size request
happens before the realization some pixels for the inset will be added
later, when the theme data is loaded. I think for the framebuffer,
unlike to the x11 engine, the engine should take care of
2008/12/16 Matteo matteo.brich...@gmail.com:
compiling with:
gcc my_widget.c 'ewl-config --cflags --libs'
And the compiler doesn't find Ewl.h, there is something I still missing?
ewl-config is probably an old script. Everything is using pkg-config these days.
E.g.
[...@rak ~]$ pkg-config
Graham Gower schrieb:
Peter Wehrfritz wrote:
Graham Gower schrieb:
Peter Wehrfritz wrote:
I committed it without the @EVAS_LIBS@, because Vincent told me that
it is not needed. Can you check please if it works now? Since I don't
have ecore_fb installed, I cannot test it
Graham Gower schrieb:
Peter Wehrfritz wrote:
I committed it without the @EVAS_LIBS@, because Vincent told me that
it is not needed. Can you check please if it works now? Since I don't
have ecore_fb installed, I cannot test it myself.
Yes, this works fine.
Nice :)
One other issue which
Peter Wehrfritz wrote:
Graham Gower schrieb:
Peter Wehrfritz wrote:
I committed it without the @EVAS_LIBS@, because Vincent told me that
it is not needed. Can you check please if it works now? Since I don't
have ecore_fb installed, I cannot test it myself.
Yes, this works fine.
Nice :)
Graham Gower schrieb:
Hi,
When EWL is configured with --enable-fb, the EWL engine evas_fb.so
fails to be dlopen()able due to missing symbols. The missing symbols
can be found in -lecore_fb.
-Graham
--- Makefile.am 2008-12-09 18:23:18.0 +1030
+++
Peter Wehrfritz wrote:
I committed it without the @EVAS_LIBS@, because Vincent told me that it
is not needed. Can you check please if it works now? Since I don't have
ecore_fb installed, I cannot test it myself.
Yes, this works fine.
One other issue which may require attention is
2008/11/25 Toma [EMAIL PROTECTED]
Hey folks,
With a new default theme in E17, its probably a good time to start
thinking about other ways to get themes from other themes. Theres the
obvious method of cramming an ETK and EWL theme into the E17 theme,
but that wont work for the default theme
On Wed, 29 Oct 2008 09:23:17 + Quaker [EMAIL PROTECTED] babbled:
i don't see how it wouldn't work. code seems ok to me - builds for me too... :/
Hi,
i tried to compile EWL with sources from 26.10, it didn't work..
i am not a C coder, but i tried to correct it, i modifed a source file
Carsten Haitzler (The Rasterman) schrieb:
On Wed, 29 Oct 2008 09:23:17 + Quaker [EMAIL PROTECTED] babbled:
i don't see how it wouldn't work. code seems ok to me - builds for me too...
:/
Sorry, my bad. I haven't answered to the list. I fixed it some days ago.
So indeed it should
On Sat, Oct 4, 2008 at 10:12 AM, Diogo Dutra [EMAIL PROTECTED] wrote:
Hi,
I am creating a app in evas/edje, but I would to put some widgets in
the app, I did it, but the widget is not accessible, a button for
example is not clickable.
Have a way to do this!? If yes, please tell me!
I tested
Im sorry, I dont gave the information correctly.
I will explain better.
I put a EWL widget in the evas/edje application, the widget appears,
but is not usable.
I want to put a entrybox widget in my application, to the user type something..
In etk I put the entrybox easily and works fine, but in
You should decompile the default.edj that comes with EWL. It's a start.
On Aug 29, 2008, at 2:44 PM, Veli Ogla Sungutay wrote:
hey all
Is there any documentation samples on theming EWL applications? I
got the
latest svn tree and I think there is a start with
doc/tutorials/themeing.dox
You can also enable Print theme signals and Print theme keys in
ewl_config for some more information.
On Fri, Aug 29, 2008 at 3:56 PM, Jorge Mariani [EMAIL PROTECTED]wrote:
You should decompile the default.edj that comes with EWL. It's a start.
On Aug 29, 2008, at 2:44 PM, Veli Ogla Sungutay
thanks guys I'll try. by the way I just saw the ewl_embed_test. Veri
interesting.
On Sat, Aug 30, 2008 at 12:04 AM, Veli Ogla Sungutay [EMAIL PROTECTED]
wrote:
thanks guys I'll try. by the way I just saw the ewl_embed_test. Veri
interesting.
On Fri, Aug 29, 2008 at 11:13 PM, Jaime Thomas
Hi Dariusz,
Thanks for the bug report on this issue. I'll take a closer look at
this and see about getting a fix in the next couple days, but feel
free to submit a patch before I get to it.
Thanks,
Nathan
2008/4/28 Dariusz KnociĊski [EMAIL PROTECTED]:
Hi,
I found memory leak in procedure
Hey,
fixed in cvs (with a small modification). Thanks
Vincent
On Thu, 17 Apr 2008, Manfred Gruber wrote:
hi !
here is a small patch for compiling ewl for fb, evas-fb is the package to
search for, not evas-framebuffer
Index: ewl/configure.in
[EMAIL PROTECTED] schrieb:
Just adding a +1 to this. I have had similar difficulties theming
Gtk+ in the past. I admire the old Athena (Xaw) and Motif widget sets
because they grant the 'themer' the ability to pick out a widget based
on it's parents names and classes as well as it's own. It
On 1 Apr, Peter Wehrfritz wrote:
We had already some discussion in the bugtracker (bug #381) about this
issue, but I want to give it a wider audience. To give you a short
overview about the discussion, here the it is in a nutshell. It started
with the question, if the checkbutton needs to
Jose Gonzalez wrote:
However you have it (though rel coords would seem best),
if you really want ewl to be a flexible tool for building
artistic, rich apps, then you'll want a natural way to
arbitrarily position child *widgets* - not just evas objects..
and to allow for
However you have it (though rel coords would seem best),
if you really want ewl to be a flexible tool for building
artistic, rich apps, then you'll want a natural way to
arbitrarily position child *widgets* - not just evas objects..
and to allow for custom kinds of child
On Thu, Mar 20, 2008 at 6:56 AM, Jose Gonzalez [EMAIL PROTECTED] wrote:
Just to make it a bit more flexible though, let's also
allow for 'importing' evas objects - if possible (not sure if ewl
has this at the moment, but just in case).
The way we usually do this is outlined in the
Dan wrote:
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the container code and allow
for
dan sinclair schrieb:
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the container code and allow for
Jose Gonzalez wrote:
Dan wrote:
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the
Peter Wehrfritz wrote:
dan sinclair schrieb:
Currently Ewl positions widgets based on absolute coordinates. This
works but isn't unnecessarily optional. Thoughts on changing the
internals of Ewl to use parent relative placement of widgets?
This would, hopefully, simplify some of the
You can do this now with Ewl. The only problem being, everything
is absolute coordinates which is a bit strange for this kind of
widget. If you want to do this, inherit ewl_box, remove configure
event, add your own configure and use ewl_object_place to put the
widgets where you want
On Wed, Mar 19, 2008 at 11:42 PM, Jose Gonzalez [EMAIL PROTECTED] wrote:
However you have it (though rel coords would seem best),
if you really want ewl to be a flexible tool for building artistic,
rich apps, then you'll want a natural way to arbitrarily position
child *widgets* - not
Jose Gonzalez wrote:
You can do this now with Ewl. The only problem being, everything
is absolute coordinates which is a bit strange for this kind of
widget. If you want to do this, inherit ewl_box, remove configure
event, add your own configure and use ewl_object_place to put the
However you have it (though rel coords would seem best),
if you really want ewl to be a flexible tool for building
artistic, rich apps, then you'll want a natural way to
arbitrarily position child *widgets* - not just evas objects..
and to allow for custom kinds of child widget
Am Sat, 16 Feb 2008 16:24:37 -0500 schrieb Jaime Thomas:
You could try the detour theme at http://code.google.com/p/detour/.
It isn't totally complete, but most things are there.
Looks very good, but the menubar in ewl still looks not fine. :-(
Not sure if this is a theme or toolkit topic.
Are you talking specifically about the menubar in the menubar test or
in another case? The menubar test is not a good example for
aesthetics, as it is intended to test as much menubar related
functionality as possible.
On Sat, Feb 23, 2008 at 2:24 AM, Andreas Volz [EMAIL PROTECTED] wrote:
Am
Am Sat, 23 Feb 2008 14:37:47 -0600 schrieb Nathan Ingersoll:
Are you talking specifically about the menubar in the menubar test or
in another case? The menubar test is not a good example for
aesthetics, as it is intended to test as much menubar related
functionality as possible.
I'm talking
Ephoto or ecdb both use more the menubar in a more normal way.
http://ecdb.googlecode.com/svn-history/r97/trunk/ecdb/doc/ecdb.png is a
screenshot of the latter.
-
This SF.net email is sponsored by: Microsoft
Defy all
You could try the detour theme at http://code.google.com/p/detour/. It
isn't totally complete, but most things are there.
Jaime
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio
Does ewl have something like a canvas widget that one can add
evas objects to?
Not atm.
That seems to me like it might be a BIG problem for any
sufficiently flexible use of ewl and evas. :(
Until a more generic solution presents itself, why not have
a separate Ewl_Evas
On Fri, Feb 15, 2008 at 2:01 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
That seems to me like it might be a BIG problem for any
sufficiently flexible use of ewl and evas. :(
Until a more generic solution presents itself, why not have
a separate Ewl_Evas lib, with say a
Until a more generic solution presents itself, why not have
a separate Ewl_Evas lib, with say a 'ewl_evas' widget, that has
a function to get an underlying evas..?
Getting to the evas is not a problem:
embed = ewl_embed_widget_find(some_widget_on_my_evas);
evas = embed-canvas; /*
On Fri, Feb 15, 2008 at 3:50 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Umm... It still sems to me like you'd want some kind of canvas
widget to which one could add arbitrary evas objects to, directly or
indirectly (I believe that etk has something like that), in order to
have
Umm... It still sems to me like you'd want some kind of canvas
widget to which one could add arbitrary evas objects to, directly
or indirectly (I believe that etk has something like that), in
order to have a more flexible evas objs in a ewl app system, and
just feed ewl events on
On Fri, Feb 15, 2008 at 10:05 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Good questions.. Don't know. A buffer canvas would be nice to
have for several reasons, but as you mention it may not be the best
way to realize a canvas widget for other reasons.. it also depends on
the
On Feb 15, 2008, at 8:36 PM, Nathan Ingersoll wrote:
snip
Yeah, unfortunately my participation at SCALE fell through. I'm not
sure if raster made it, but it would be good to hear a trip report if
he did. :-)
Another wrinkle is that we'd like to create a core library that is
only loosely tied to any specific underlying display system. We're
still in the process of abstracting the evas and edje specifics into
engines, and I don't want to add too many more direct dependencies.
This could be done as
The answer is yes and no. You can certainly do this simply by mapping
the theme for a widget to your Edje. The problem is that any events
will automatically have the source set as EWL instead of the clicked
part. The problem is that we do dispatching to the widget inside of
EWL, and w/o an API to
Nathan wrote:
The answer is yes and no. You can certainly do this simply by
mapping the theme for a widget to your Edje. The problem is that
Is mapping the theme for a widget to your Edje a standard,
well-known thing to do in ewl? Is that the same as using one's own
edj file
On Fri, Feb 15, 2008 at 12:18 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Nathan wrote:
The answer is yes and no. You can certainly do this simply by
mapping the theme for a widget to your Edje. The problem is that
Is mapping the theme for a widget to your Edje a
It appears that make may also be touching the output files during
parallel builds, probably as some kind of locking or synchronization
mechanism. So the actual compilation phase was finding existing files
of size zero, which eet was treating as an invalid file.
On Nov 30, 2007 2:25 PM, Sebastian
Nathan Ingersoll wrote:
You're probably right that a dep could fix the build failure, but it
would be better if we could determine why edje_cc is failing and fix
that. These really are independent directories with no shared files,
especially on the output.
Doesn't make just check whether the
The e17 theme and the ewl_embed_test theme are totally independent.
There is no shared code, or anything else, between them.
dan
On 30-Nov-07, at 10:25 AM, Martin Zwickel wrote:
On Fri, 30 Nov 2007 09:03:40 -0500
Will Keaney [EMAIL PROTECTED] bubbled:
FWIW, I've noticed that when
On Fri, 30 Nov 2007 09:03:40 -0500
Will Keaney [EMAIL PROTECTED] bubbled:
FWIW, I've noticed that when building with -j 1, if I retry the make
twice it works (so, three 'make' commands in all). So rather than a
dep, I suspect a race condition between the threads.
That's what I meant. A
Martin Zwickel wrote:
Hi there,
If I try to build ewl with 4 jobs, the make returns with an error. Seems like
there is a missing dependency? Build with 1 job works ok.
Regards,
Martin
[output]
# make -j4
...
Making all in images
make[5]: Entering directory
This appears to be a problem with multiple simultaneous executions of
edje_cc, as it always fails the build during that phase. I have not
tracked it past that point yet.
On Nov 30, 2007 8:03 AM, Will Keaney [EMAIL PROTECTED] wrote:
Martin Zwickel wrote:
Hi there,
If I try to build ewl
You're probably right that a dep could fix the build failure, but it
would be better if we could determine why edje_cc is failing and fix
that. These really are independent directories with no shared files,
especially on the output.
On 11/30/07, Martin Zwickel [EMAIL PROTECTED] wrote:
On Fri, 30
Hi Vincent,
I thought ecore had been updated but I found out that the
rpm engine didn't allow my script to install ecore because of the following:
---
error:
It can't run on evas directly as it needs to know how to receive mouse
and key events. But, the Ewl engines are setup with dependencies. So, if
you take a look at evas_fb at the top you'll see an
ewl_engine_dependencies function that declares evas as it's parent.
It then just implements the
Ephoto, e17/apps/ephoto is probably the most in depth ewl application right
now. There is also empower and then some various applications on
http://e-app-dev.blogspot.com/
On 5/14/07, Jackson! [EMAIL PROTECTED] wrote:
Hi there,
I'm a pretty callow programmer (most of my recent experience is
Peter Parkanyi wrote:
Ephoto/EWL(I don't know which is the guilty one):
I started ephoto, with the simple command, then navigated to my pictures on
the upper list, all with mouse. Then wanted to click on the image, but it
didn't get coloured while the mouse was hovering. Clicked, then the
On Tuesday, 27 June 2006, at 14:09:37 (-0400),
dan sinclair wrote:
Ewl currently doesn't have, and we're purposely holding off on,
translation support. We do plan to build it in, but putting it in
too soon just means the translations will continuously keep getting
changed and updated, so
On Tuesday 27 June 2006 20:09, you wrote:
I'm assuming your in either the list or column view?
I don't see any options in ephoto's file chooser bar on the left where i could
change the mode. I suppose it is just the default :)
Ewl currently doesn't have, and we're purposely holding off on,
dan sinclair wrote:
Ewl doesn't currently have a modal setting. I've started work to add
one, but the setting dosen't seem to be taking any effect. I've done it
the same way I did the fullscreen setting so it maybe that I've made the
same mistake in both places.
Hopefully once we get
Sebastian Dransfeld wrote:
Remember to set the window which the client is transient for too. Else
it wont work. See lines 5237-5250 in e_border.c
Hm, I have it set transient_for but doesn't seem to be working. It isn't
an e17 thing as it doesn't work in gnome either. Not sure what I'm
http://en.wikipedia.org/wiki/Modal_windowOn 6/5/06, Rafael Ugalde
[EMAIL PROTECTED] wrote:Can I set one dialog windows to be modal, example: One application display dialog to exit ( yes / no ) dialog. The user must select any of this but can't interactuate with the windows app, only with the
Ewl doesn't currently have a modal setting. I've started work to add
one, but the setting dosen't seem to be taking any effect. I've done it
the same way I did the fullscreen setting so it maybe that I've made the
same mistake in both places.
Hopefully once we get fullscreen worked out I can
On 4/15/06, Peter Wehrfritz [EMAIL PROTECTED] wrote:
Hi all,
While I'm playing around with ewl_embed to replace my old context menu
in elitaire, I recognize that this is nearly impossible, because ewl
spreads its objects over the whole layer range, starting with -1000 upto
1000 (I'm not sure
Nathan Ingersoll schrieb:
On 4/15/06, Peter Wehrfritz [EMAIL PROTECTED] wrote:
Hi all,
While I'm playing around with ewl_embed to replace my old context menu
in elitaire, I recognize that this is nearly impossible, because ewl
spreads its objects over the whole layer range, starting with
We are also hoping, time permitting, to integrate some more tutorial
type information to the test application. So currently, when you run
your test, it will show the source code for that particular test in one
of the tabs. We want to also show a tutorial style introduction to that
widget as
On 3/12/06, dan sinclair [EMAIL PROTECTED] wrote:
If you're interested in doing some learning about EWL this is anexcellent opportunity. You can dig in, play with things, and then fillout a tutorial on the widget. Take a look a the src/bin/tests/ewl_text.c
for an idea on how to do the
Thanks, that works a treat.
There is now another ewl issue I noticed, it seems to assume a US
keyboard mapping, and so I cannot type the GBP sign and some keys are
the wrong way round - any ideas what that could be?
Andy
On Thu, Mar 02, 2006 at 09:00:54PM -0500, dan sinclair wrote:
Andrew
Andrew Williams wrote:
I tried to trace this and figure out what is happening, but failed, so
am posting this to the list:
Ewl entries in embeded windows do not print symbols, any modifier is
sent through the key even system as a key down it seems.
my tracing lead me to:
ewl_ev_x_key_down(void
On Tue, 24 Jan 2006 19:06:04 -0500 Daniel Kozlowski [EMAIL PROTECTED] babbled:
Looking thorugh the CVS tree as i was experementing with EFL i noticed
ETK which seemed to be an alternative widget set to EWL ( though i have
found no documentation on it) Then when trying to talor a EWL
On 1/8/06, Ben Ford [EMAIL PROTECTED] wrote:
The docs for EWL make it seem to be a container based toolkit instead ofpixel based.Still, I am finding myself having to specify exact pixelsizes for many of the widgets that I am using (and even then, some don't
want to behave right.)Are there known
Ben Ford wrote:
Nathan Ingersoll wrote:
ewl_simple_test needs updating badly. Use ewl_test and click on the
various test modes, or use ewl_test test name
I should have made it clear that I tried all of the executables and
they all crashed. I'll go build a fresh checkout of everything and
On Thu, 2006-01-05 at 04:08, Ben Ford wrote:
ewl_test is still broken, but I was able to create a working notebook by
puzzling through the source.
Ewl_Test is working fine here. Can you please send a backtrace or some
indication of why it is broken as we aren't seeing any issues. (You have
On Thu, 2006-01-05 at 04:14, Ben Ford wrote:
A problem that remains is that this returns zero (as it should!) on an
empty notebook, but it still barfs errors to stderr.
* Ewl Developer Warning * :
To find where this is occurring set a breakpoint
for the function
dan sinclair wrote:
On Thu, 2006-01-05 at 04:08, Ben Ford wrote:
ewl_test is still broken, but I was able to create a working notebook by
puzzling through the source.
Ewl_Test is working fine here. Can you please send a backtrace or some
indication of why it is broken as we aren't
On 1/5/06, Ben Ford [EMAIL PROTECTED] wrote:
I know that I can create an Evas object on the framebuffer myself.CanI make an Ewl app on the framebuffer?EWL has an fb engine, though it's limited to a single window for the application right now. Run any app with --ewl-help to see the list of
Thanks, I didn't know the difference between those sets of functions.
The API ref here:
http://www.enlightenment.org/doxy/ewl/group__Ewl__Text.html doesn't make
it too clear ;)
I'm gearing up to do a major overhaul on the EWLBook which will hopefully get a
lot of things cleared up.
Take a look at the ewl_notebook_test in the src/bin directory of ewl.
dan
On Tue, 2006-01-03 at 17:38, Ben Ford wrote:
Is there an example somewhere of how to use the EWL notebook widget?
The EWL book section on notebooks is empty and I'm having trouble
getting it to work using just the
dan sinclair wrote:
Take a look at the ewl_notebook_test in the src/bin directory of ewl.
dan
Thanks. Is there a trick to running the tests?
pluto bin $ ./ewl_simple_test
No usable theme found, exiting EWL
*** ECORE ERROR: Ecore Magic Check Failed!!!
*** IN FUNCTION:
On Tuesday 06 December 2005 08:05, Falko Schmidt wrote:
Hi,
I'm stuck here with some ewl-related problems since several days.
First, there's an issue with a configuration interface that I'm trying
to write. I think the easiest way is to describe my intension:
I hope it isn't too confusing.
On Tue, Dec 06, 2005 at 08:54:37AM -0600, Brian Mattern wrote:
On Tuesday 06 December 2005 08:05, Falko Schmidt wrote:
Hi,
I'm stuck here with some ewl-related problems since several days.
First, there's an issue with a configuration interface that I'm trying
to write. I think the
Moving these to a separate SVN repository seems to be the most politically expedient option.On 11/4/05, Andrew Williams
[EMAIL PROTECTED] wrote:I think thata) I have not been doing my part in keeping the theme up to date
b) skeleton was really only put in to dmonstrate the theme switching inewl
after thinking about things a bit more, and reading raster's email re
unmaintained modules cluttering up cvs, i had just decided that themes
probably shouldn't go into the main cvs. then i got to this email... so,
wonderful idea. :)
personally, I prefer svn over cvs. we can easily give people
On Thu, 3 Nov 2005 08:18:08 -0600 Brian Mattern
[EMAIL PROTECTED] wrote:
personally, I prefer svn over cvs. we can easily give people access
to _Just_ their theme dir. and symlinks to sort things by app should
not be a problem.
I prefer svn to. sf.net claims that svn is coming.
I'd like input from HandyAndE and rephorm in particular on this one as they are original authors on two of them.On 11/2/05, dan sinclair
[EMAIL PROTECTED] wrote:Hello,Nathan and I have been looking at the themes for EWL and have realized
that zero, default and skeleton are woefully unmaintained
dan sinclair [EMAIL PROTECTED] [2005-11-02 11:25]:
We could either do a separate CVS directory, or move them to
edevelop.org and depend on the ability for .edj's to be de-compiled to
let people get the source code.
What's the point of option 1?
Doesn't matter whether they are unmaintained in
Hey,
I've been meaning to get back to the winter ewl theme (and some ewl-e17 theme
touchups), but keep getting distracted by other things :) In the mean time, I
would agree with splitting them out.
Really, it would be nice to create an e17/themes dir in the repo, so we'd have
a central place
What's the point of option 1?
Doesn't matter whether they are unmaintained in 'ewl_themes' or in
'ewl'.
You can remove the offending directories from the SUBDIR variables in
Makefile.am, so they won't be distributed etc.
If anyone succeeds in fixing them, you can put them in again.
Well,
Brian Mattern wrote:
Really, it would be nice to create an e17/themes dir in the repo, so we'd have
a central place for theme source. This would make it easier for people to go
through and patch themes on theme API changes (when the original authors are
too busy to do it themselves).
I
On 10/19/05, Nathan Ingersoll [EMAIL PROTECTED] wrote:
*snip*
If anyone has questions or comments about any of these developments or
anything else EWL related, please reply to the list so we can keep more
people in the loop.
Sorry to bug. I know this might not be the main priority but I'm
Things like these:
* Ewl Developer Warning * :
To find where this is occurring set a breakpoint
for the function ewl_print_warning.
This program is calling:
ewl_widget_type_is();
With the parameter:
widget
being NULL. Please
On Tuesday, 18 October 2005, at 23:09:07 (-0500),
Nathan Ingersoll wrote:
I have never liked the parameter inconsistency in the widget constructor
calls, but have been content to support them as people are used to it from
other toolkits, and it can save them some extra lines of code. As part
Yep, just may do that at some point.On 10/21/05, Michael Jennings [EMAIL PROTECTED] wrote:
On Tuesday, 18 October 2005, at 23:09:07 (-0500),Nathan Ingersoll wrote: I have never liked the parameter inconsistency in the widget constructor calls, but have been content to support them as people are
If anyone has questions or comments about any of these developments or
anything else EWL related, please reply to the list so we can keep more
people in the loop.
Just as an addon to this, one of the more turbulent reworks I've been doing (on
the backburner for a while) is redoing the
this has previously been fixed, please update
[EMAIL PROTECTED] wrote:
Attached patch fixes breakage in ewl_config resulting in changes from
PF_foo to ECORE_CONFIG_FLAG in ecore_config. Please commit :)
Ryan
Index:
Heck, sorry - did not see this was the origional, it seems my mailbox is
having fun undeleting and marking as new some of my old emails...
[EMAIL PROTECTED] wrote:
Attached patch fixes breakage in ewl_config resulting in changes from
PF_foo to ECORE_CONFIG_FLAG in ecore_config. Please commit
The table widget needs some updating. It doesn't correctly setup it's
sizing, so if the tree widget is an option for you, I'd recommend
trying that. It needs more work too, but it is a better supported
widget right now.On 9/5/05, Paulo Matos [EMAIL PROTECTED] wrote:
Hi all,I'm developing a E17 app
OK, I'll try the tree widget then... thanks...
Nathan Ingersoll said:
The table widget needs some updating. It doesn't correctly
setup it's
sizing, so if the tree widget is an option for you, I'd
recommend trying
that. It needs more work too, but it is a better supported
widget right now.
1 - 100 of 149 matches
Mail list logo
