pikture-devel Mailing List for Pikture
Status: Pre-Alpha
Brought to you by:
ferratus
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|
From: Jonathan G. <jgr...@li...> - 2004-07-29 16:25:20
|
Carl Pelletier wrote: > Ok nice, that show that they do nothing really special. Great point :-) > > I make a couple of search on google and I saw many talk about the > performance issue with the thumbnails sliders. So, sure it's realy hot > looking feature, but is that realy usefull? meaby we can provide like > 2 to 6 predefined size? Imagine a guy who have 800 pictures in a album > or in a search result album, this will not decrease the performance of > the application ? I not convinced that is a pratical feature. It's > look good, but is that realy important? Give me your opinion on that. > > > I started to look at imageMagick C++ API, this thing realy ROCK :-) I > think we must use it. This thing have been develop exactly for what we > wont to do. And it's look to be realy easy to use. > > More on this realy soon. > > What tool you will use to make the uml ? Cause I want to do the same > for the gphoto API and the imagemagick one. > > I saw only 2 not quite ready open source projet yet: umbrello from KDE > and dia from gnome. > Ok, I finally have some time to answer. Sorry for the very slow response time... I came back home yesterday at 11:30PM and didn't have to to reply yesterday during the day either. Concerning UML, Umbrello is absolutly fantastic so far. It works great and has gets the job done really well. I've been using it for a while at work too and I havne't had a single problem with it yet. That's what I am using for pikture. For ImageMagik, I know it's really well done. All I want to make sure is that KDE doesn't already have these capabilities built-in. If it does, then we'll use KDE isntead. Otherwise, ImageMagik is the first choice. Concerning iPhoto, there is no performance problem in iPhoto with the slider. Quite the contrary in fact. It works really well even on older hardware like mine. iPhoto *is* slow to load and display thumbnails...but this has largely been fixed in the latest version and the problem is not with the slider...merely the way they load data. I've been studying their files and it's pretty weird. They have several .db binary file that they seem to load every time + the lib itself is in a plist file, which is a glorious name for an XML file with a lot of overhead :) Not exactly the best way to do so. We will have a good advantage here. File I/O is also quite slow on PPC for some reason, so again we should get some gain there. I really think we need this...it works great and people love it. It's the kind of eye candy that makes Apple products "cooler" and that's what people want. No point in not giving it to them. If you hardware is too slow, then simply don't use it...so it's available for those with proper hardware and the rest can deal with small thumbnails. Another thing that makes Apple's display slow is that they actually draw a shadow beneath each thumbnail! It looks cool, but it's way too slow. We'll have more time to discuss this tonight anyway. |
From: Carl P. <ca...@2b...> - 2004-07-28 13:10:17
|
Jonathan Grenier wrote: > Ends up I was wrong. iPhoto has a "Thumbs" directory containing all the > thumbnails for a particular directory. For my photos (high-res) they are > 239x180. There's only 1 thumbnail per photo. > > They also create a "Originals" folder with the unmodified photos. This > is used when you rotate/change the photo in any way. The original is > kept there so you can undo at any time. > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Pikture-devel mailing list > Pik...@li... > https://lists.sourceforge.net/lists/listinfo/pikture-devel Ok nice, that show that they do nothing really special. Great point :-) I make a couple of search on google and I saw many talk about the performance issue with the thumbnails sliders. So, sure it's realy hot looking feature, but is that realy usefull? meaby we can provide like 2 to 6 predefined size? Imagine a guy who have 800 pictures in a album or in a search result album, this will not decrease the performance of the application ? I not convinced that is a pratical feature. It's look good, but is that realy important? Give me your opinion on that. I started to look at imageMagick C++ API, this thing realy ROCK :-) I think we must use it. This thing have been develop exactly for what we wont to do. And it's look to be realy easy to use. More on this realy soon. What tool you will use to make the uml ? Cause I want to do the same for the gphoto API and the imagemagick one. I saw only 2 not quite ready open source projet yet: umbrello from KDE and dia from gnome. I have a big problem right now, I need some time to sleep :-( -- Carl Pelletier ca...@2b... |
From: Jonathan G. <jgr...@li...> - 2004-07-28 03:44:15
|
Ends up I was wrong. iPhoto has a "Thumbs" directory containing all the thumbnails for a particular directory. For my photos (high-res) they are 239x180. There's only 1 thumbnail per photo. They also create a "Originals" folder with the unmodified photos. This is used when you rotate/change the photo in any way. The original is kept there so you can undo at any time. |
From: Jonathan G. <jon...@so...> - 2004-07-27 04:35:37
|
Pending a full-fledged roadmap (to be published after 0.1), here's the goals of our first public release 0.1. - Minimal with standard menus and actions. (Jon) - Library management including albums, tags and photos. (Jon) - Thumbnail display with minimal infos such as rating and name. (Jon) - Import from camera with custom library on top of libgphoto. (Carl) - Thumbnail generation with possible imagemagik integration. (Carl) Planned release date : September 3 2004. |
From: Jonathan G. <jon...@so...> - 2004-07-17 07:40:41
|
Quick status update on my end. I've basically decided to scrap the new classes and structure I had for the entire back-end and start over :) I'll work on that tomorrow. I think that's the best thing to do because the architecture I had designed simply didn't scale enough. I realized that while it did work now, it probably wouldn't in 6 months, hence the decision to start over. Basically, here's what I want to do now: The Library class will hold all your library-related data. That is to say, the library itself, the photos, the albums, the tags, etc. This info will be held in QT-collections and will have methods to Add/Remove/Edit them as needed. For example, the Library object will have a "addTag", "removeTag" and "editTag". It will also have similar methods for albums and photos. All of the SQLite code will be contained in this class, so that removes the need for an additional DB-layer class. Once I finish this (tomorrow, or maybe sunday), I will work on user prefs. I've read a lot on this today and it looks like it will be simplish :) Keep working on the gphoto end. Once done, we'll integrate it in pikture. If you want, you could start working on either shell integration (DCOP) or the image magik stuff. Keep the discussion on the list please. Jon |
From: <jgr...@li...> - 2004-06-28 13:46:13
|
Well ok. The glitch with the mail server should be fixed now so we should be receiving our mails now :)=20 Regarding pikture, the UI for the main window is getting better and better. I've added splitters between the widgets now so it's much more useful this way. I'll continue tonight by adding the rest of the menu items and toolbar actions. Once that's done, I can move on to the sqlite "backend". Regarging sqlite, what do we do with exernal libs dependencies ? For Sqlite, I think it's safe to integrate it in our CVS tree and simply static-link it (since it's so small). Perhaps with libgphoto and libimagemagick we can simply link to the external lib, especially since most distros have them already. What do you think ? --=20 Jonathan Grenier (jgr...@li...) GPG Key ID : D26C7823 [http://www.jonscorner.com/pubkey.php] |