[E-devel] another small bug in entrance
Hi guys, I encountered another minor bug with entrance. Entrance locks up when I swih to a differnt VT and back. I submitted a bugreport to http://xcomputerman.com/bugs see there for all the details (not much really) Cheers Jochen --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] another small bug in entrance
On Sun, 15 Feb 2004 17:23:52 +0100 Jochen Schroeder <[EMAIL PROTECTED]> (Bbabbled: (B (B> Hi guys, (B> I encountered another minor bug with entrance. Entrance locks up when I (B> swih to a differnt VT and back. I submitted a bugreport to (B> http://xcomputerman.com/bugs (B> see there for all the details (not much really) (B (Byeah. i've noticed that too... you're not alone. sorry - no time to debug that (Batm - got enuf other things to do. (B (B> Cheers (B> Jochen (B> (B> (B> --- (B> SF.Net is sponsored by: Speed Start Your Linux Apps Now. (B> Build and deploy apps & Web services for Linux with (B> a free DVD software kit from IBM. Click Now! (B> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click (B> ___ (B> enlightenment-devel mailing list (B> [EMAIL PROTECTED] (B> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel (B (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click (B___ (Benlightenment-devel mailing list (B[EMAIL PROTECTED] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas GL Engine and DRI (tdfx)
On Thu, 12 Feb 2004 18:29:03 -0600 (CST) "Daniel Hansen" (B<[EMAIL PROTECTED]> babbled: (B (B> > Mind sending a backtrace? The info below isn't very helpful. (B> (B> sorry about that, I really don't debug stuff that often, but here it is: (B> (gdb) backtrace (B> #0 0x406e50a7 in extract_float_rgba () (B>from /usr/X11R6/lib/modules/dri/tdfx_dri.so (B> #1 0x in ?? () (B> Cannot access memory at address 0x6 (B (Bhmm. that's not much help either. can u recompile evas with full gdb debugging? (Bie: (B (Bmake clean distclean (Bexport CFGLAGS="-g" (B./configure (Bmake (Bmake install (B (Bit might not help much either if the stack is screwed though... (Bbut warning: (B1. 3dfx doesn't support 24/32bpp textures. evas will look like a dog's festering (Bmaggot-ridden rear end with 16/12bpp textures, which is what opengl will have to (Bfall back to. trust me. i can see it here on this i810 - its god-awful. i (Bwouldn't want my most hated enemies be subjected to this pain. (B2. 3dfx has maximum texture sizes of 256x256. given the opengl engine this means (Bany images greater than 26pixels in any direction simply will not display. u (Bwill get a "white box" instead. (B3. get a new card. an ati or nvidia card is dirt stinking cheap (the lower (Benough ones) and will run RINGS around your 3dfx card in quality, performance (Beven at the $50-100 card level. (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click (B___ (Benlightenment-devel mailing list (B[EMAIL PROTECTED] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Ecore Text bug
On Tue, 10 Feb 2004 16:48:01 -0500 (EST) dan sinclair <[EMAIL PROTECTED]> (Bbabbled: (B (B> Hello, (B> (B> I was using Ecore_Txt and noticed that if my input string was corrupt it would (B> loop continuously. (B> (B> The attached patch catches the two cases where iconv throws -1 and that were (B> not already caught. In both cases it just returns NULL as the new string. I (B> don't know if this the correct way to handle it, but it will at least allow (B> it to be handled, heh. (B (Bthanks! in. :) (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click (B___ (Benlightenment-devel mailing list (B[EMAIL PROTECTED] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] another small bug in entrance
On Mon 16 Feb 2004, Carsten Haitzler wrote: > On Sun, 15 Feb 2004 17:23:52 +0100 Jochen Schroeder <[EMAIL PROTECTED]> > babbled: > > > Hi guys, > > I encountered another minor bug with entrance. Entrance locks up when I > > swih to a differnt VT and back. I submitted a bugreport to > > http://xcomputerman.com/bugs > > see there for all the details (not much really) > > yeah. i've noticed that too... you're not alone. sorry - no time to debug that > atm - got enuf other things to do. > Have I ever mentioned how much I *hate* vt switching bugs? -- Ibukun Olumuyiwa http://xcomputerman.com "Wisdom is the principal thing; therefore get wisdom: and with all thy getting get understanding." - Proverbs 4:7 --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click ___ enlightenment-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Priorities!
Ok... I've been away for the last few days so this is the "1 reply fits all" (Bmail - so if I missed something, sorry - lots of stuff there! :) (B (BOK. first. Ibukun (xcomp) - i know where you're coming from - but remember - it (Bwas this playing with "apps" that was a learning stage for you and many others. (Bi encourage people to use it to learn, but at the same time you're right - it (Bshould not become the FOCUS for people. That is why often i write a test app to (Bexercise things - get it done, then dump it and stop work in favor of something (Belse. it's a good tool for testing and learning. (B (Bbut yes - we should have a meeting. the problem is organising a time. the (Bmajority of people are in north America, with Europe probably second and well (BI'm over here in Japan... so... that gets us spreading around the world pretty (Bmuch in all timezones. many of us have "work" - some of us can use IRC during (Bwork, some can't. (B (Bso... (B (Bwhen? personally i'd say 11am Saturdays Tokyo time :) That'd be 1pm Sydney (Btime... but in the end i think it's going to be hard for everyone to make it - (Be-mail is a good medium that allows us to dicuss this without a time issue... it (Bjust takes longer :) (B (Bi will admit i haven't given evas a lot of attention of late, but its also a (Bsign of its maturity - it WORKS. there are many areas it could be improved - and (Byes large object count efficiency is one. i have some plans that could reduce (Bthe object count markedly too by adding api's for smart objects to provide PAINT (Bmethods instead of creating multiple sub-objects to do drawing. this would lead (Bthe way to extending evas directly with first-class objects just the same as (Bevas's internal objects work. evas technically could be worked on forever in its (Bown right - but i've chosen to stand back mostly as "it works" and until i NEED (Bsomething from it or find a bug it lies dormant in favor of other important (Bissues... such as edje, ecore and now e17 wm proper. (B (Becore is an ongoing expansion project - i can see it growing markedly. ecore_x (Bwill expand as e17 and other apps need x wrappers/facilities. the old ecore code (Bis still there to "steal from" as needed. i intend to add code to ecore_x as i (Bneed it as i work on e17. edje is the same. it works. i have stopped adding to (Bit as it is sufficient for e17's purposes for now. i will add to it, optimize (Band fix "as needed". it can be worked on later. (B (Bthis does NOT exclude others adding to it. ecore, edje and evas are open game (Bfor improvements - but since each of these matures and grows changing/adding (Bbecomes more of a large task so be ware of what you do and how you do it. (B (Bi have been working on e17 lately again - its not in cvs because i don't want to (Bencourage people to help just yet. i want to make it a solid foundation first. (Bwhen its ready it will go in. menus are moving along. they should be done (to (Bthe point of being sufficient for use) soon. (B (Bmy personal priorities focus towards getting e17 out the door. in the background (Bmy intention is to make every component that goes to make the wm possible (Bmodular and useful beyond the wm. i would like to later on produce a lot of cool (Buseful apps. i even would like to see E included on handheld distributions such (Bas familiar for pda's - but a stripped down "E for embedded" so to speak. i keep (Bthis in the back of my mind for everything i am working on. (B (Bnow back to e. before it goes in cvs i will flesh out my document on "how it (Bworks" and "coding standards" i have some there - but i will watch e17's code (Blike a hawk - i want this code to remain clean and beautiful from the start. (Bpreviously e has suffered from code degredation - "code rot" over time with (Bdifferent code, different styles, people, systems not interacting properly etc. (Bkwo is doing a great job of moving it along - but there's a lot of futz there (Bthat e17 is intended to clear up - and i want it to STAY CLEAR. (B (Bnow as for todo thigs that rbdpgn sent... (Bthings i don't agree with (as i agree with most): (B (Bevas: text hinting <- eh? evas does hinted truetype kerned text... ? what (Bhinting? :) (Bestyle: i have it on my todo list to bring this into evas. the massive object (Bcount (and repeated objects just at offsets and differing colours) really should (Bbe done in evas. it's on the todo list - either in evas or via smart objects (Bwith PAINT methods that draw all the text. also i want to add "filters" to evas (Bthat u can apply to an object... blur was my first candidate... :) (B (Bas for docs. user docs right now aren't much of an issue as there is no "wm" to (Binstall or configure. the libs themselves needs docs. some are fully documented, (Bsome are partially documents, some are not documented at all. we need to compete (Bthe docs for libs - and this is library api/tutorial etc. doc
Re: [E-devel] Priorities!
On Mon, Feb 16, 2004 at 04:08:35PM +0900, Carsten Haitzler wrote: > > now as for todo thigs that rbdpgn sent... > things i don't agree with (as i agree with most): > > evas: text hinting <- eh? evas does hinted truetype kerned text... ? what > hinting? :) You would need to ask xcomp about this, I wasn't quite clear on what he meant by this either. His example was a comparison of Evas font rendering to gnome, apparently Evas looked rather bad in comparison. > estyle: i have it on my todo list to bring this into evas. the massive object > count (and repeated objects just at offsets and differing colours) really should > be done in evas. it's on the todo list - either in evas or via smart objects > with PAINT methods that draw all the text. also i want to add "filters" to evas > that u can apply to an object... blur was my first candidate... :) Yay! :-) Last we talked about this, there didn't seem to be a clear decision on whether pixel level access to text would be available. If that will be possible, then I'm all for estyle either a) moving into evas or b) adapting to the availability of these features. > as for docs. user docs right now aren't much of an issue as there is no "wm" to > install or configure. the libs themselves needs docs. some are fully documented, > some are partially documents, some are not documented at all. we need to compete > the docs for libs - and this is library api/tutorial etc. docs. the docs need to > go in the code as javadoc comments that doxygen processes. thats the priority in > the doc world atm. anyone who likes docs is invited to discuss maybe a better > way of generating the docs, but i think the javadoc format within the code is > here to stay. it is an industry standard... At this point, I would be more inclined to spend time writing more actual documentation than messing the tool that generates the end docs. API doc's are nice, but the "cookbook" is far more important. Ideally, we would have a set of introductory articles for each major lib. Lots to do indeed. -- | Nathan Ingersoll \\ Computer Systems & Network Coordinator | | [EMAIL PROTECTED] \\ http://www.ruralcenter.org| | http://ningerso.atmos.org/ \\ Rural Health Resource Center | signature.asc Description: Digital signature
Re: [E-devel] Priorities!
On Mon, 16 Feb 2004 01:44:40 -0600 Nathan Ingersoll (B<[EMAIL PROTECTED]> babbled: (B (B> On Mon, Feb 16, 2004 at 04:08:35PM +0900, Carsten Haitzler wrote: (B> > (B> > now as for todo thigs that rbdpgn sent... (B> > things i don't agree with (as i agree with most): (B> > (B> > evas: text hinting <- eh? evas does hinted truetype kerned text... ? what (B> > hinting? :) (B> (B> You would need to ask xcomp about this, I wasn't quite clear on what he (B> meant by this either. His example was a comparison of Evas font (B> rendering to gnome, apparently Evas looked rather bad in comparison. (B (Bhmm - we could be calculating kerning differently with sub-pixel co-ords... not (Bsure though. evas does its position in 26.6 sub-pixel positioning (then a glyph (Bwill be placed rounded down to the nearest pixel position) (B (B> > estyle: i have it on my todo list to bring this into evas. the massive (B> > object count (and repeated objects just at offsets and differing colours) (B> > really should be done in evas. it's on the todo list - either in evas or via (B> > smart objects with PAINT methods that draw all the text. also i want to add (B> > "filters" to evas that u can apply to an object... blur was my first (B> > candidate... :) (B> (B> Yay! :-) Last we talked about this, there didn't seem to be a clear (B> decision on whether pixel level access to text would be available. If (B> that will be possible, then I'm all for estyle either a) moving into evas (B> or b) adapting to the availability of these features. (B (Boh oh.. no - not pixel-level access to the text. the filter idea would be (Binternal so u say evas_object_filter_set(o, "blur", "10"); to indicate this (Bobject is to blur 10 pixels... whatever object it is. i'm not clear on the api (Byet tho... :) (B (B> > as for docs. user docs right now aren't much of an issue as there is no "wm" (B> > to install or configure. the libs themselves needs docs. some are fully (B> > documented, some are partially documents, some are not documented at all. we (B> > need to compete the docs for libs - and this is library api/tutorial etc. (B> > docs. the docs need to go in the code as javadoc comments that doxygen (B> > processes. thats the priority in the doc world atm. anyone who likes docs is (B> > invited to discuss maybe a better way of generating the docs, but i think (B> > the javadoc format within the code is here to stay. it is an industry (B> > standard... (B> (B> At this point, I would be more inclined to spend time writing more (B> actual documentation than messing the tool that generates the end docs. (B> API doc's are nice, but the "cookbook" is far more important. Ideally, (B> we would have a set of introductory articles for each major lib. (B (Byup. cookbook is very important. doctools - i'm not planning on doing much (Bmyself. just writing docs (when i get to it). how those comments in the C code (Bbecome a document.. is another matter (B (B> Lots to do indeed. (B> (B> -- (B> (B> | Nathan Ingersoll \\ Computer Systems & Network Coordinator | (B> | [EMAIL PROTECTED] \\ http://www.ruralcenter.org| (B> | http://ningerso.atmos.org/ \\ Rural Health Resource Center | (B> (B> (B> (B (B (B-- (B- Codito, ergo sum - "I code, therefore I am" -- (BThe Rasterman (Carsten Haitzler)[EMAIL PROTECTED] $B7'<*(B - $Bhttp://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click (B___ (Benlightenment-devel mailing list (B[EMAIL PROTECTED] (Bhttps://lists.sourceforge.net/lists/listinfo/enlightenment-devel
