On 9/15/06, Banlu Kemiyatorn <[EMAIL PROTECTED]> wrote:
On 9/15/06, Nicolas Roard <[EMAIL PROTECTED]> wrote: > On 9/15/06, Banlu Kemiyatorn <[EMAIL PROTECTED]> wrote: > > On 9/13/06, Nicolas Roard <[EMAIL PROTECTED]> wrote: > > > Frankly I think we should simply work on adding formats in GNUstep: > > > 1) it's not really difficult > > > 2) it would benefit _everybody_ instead of just one program :-) > > > > But we'll need progressive loading mechanism and there is no API for doing > > such thing in GNUstep currently AFAIK. > > 1) I don't think we *need* (absolutely) progressive loading. Having > such a mechanism is nice, of course, but even without it I'd be more > than happy :-) It would be a very low responsive image viewer without that.. The app'll probably need it one day if we want our applications to compete with the others. So why don't we at least try to prepare some API design? It should be easy.
It really depends which kind of app you have in mind -- if it's something to browse 2000 images at the same time, then yes, progressive loading is necessary. But I'm more thinking of a Preview.app-like, really. Eg a simple image viewer, click on a file and display it, that's all.
> 2) Anyway I don't think it's very hard to actually implement such a > progressive loading mechanism -- you'll simply need to have a task > that add a new bitmapimagerep to your NSImage, and then signal it to > the program (and the signaling/redraw part is perhaps already done, > not sure about that). I mean, the complexity of a progressive loading > mechanism -- outside the capacity of loading incrementally bigger (note that capacity of loading incrementally bigger is everything I want)
I wasn't clear; what I meant was, to know how to load the partial images -- not how to do a progressive display, as that's already easily done via NSImage and the NSBitmapImageRep mechanism as far as I can see.
> images, but that should be part of the image library anyway -- only > lies in beeing able to deal with multiple representations of your > image, etc. Well, NSImage already provides that mechanism :-) > > So I'd say, let's forget about the progressive loading for the moment, I don't understand your let's forget about it now attitude. Somebody would probably have to spend a lot of time choosing the way he/she implement something. Why don't we discuss the future limitations now so they don't have to spend their valuable time on something that could be replaced? My point is, it is better to study the problem now and decide what to do before you start doing it. And spend your valuable time to design something that really need serious thoughts.
I agree; but what I'm saying is that on the API side, not much will change, if anything will. You simply create an NSImage and display it. Possibly an EProgressiveImage if you want, but really that'd be the same (api-wise) -- the only addition you need, on the application side, is to be warned when a new imagerep is available and to ask for a redisplay of the image. Hardly complex to do, and it probably will be completely automatic anyway (at worse, a notification can be send, but even there, NSImage -- or our own EProgressiveImage -- can be modified to catch the notification and redisplay itself, so, really, the application doesn't need to deal with such a progressive display itself). That's all I'm saying, really -- that the API won't change much at all, and likely not at all... So I was simply advocating to do a simple Preview.app-like application and be done with it, and then later on we can add progressive rendering capacities if we want, but the modifications /on the application/ will be extremely minimal, and very likely nothing will even need to be modified. That doesn't mean that the mechanism itself isn't quite some work and that you won't need to modify quite a bit NSImage -- you will. But on the app-side, nothing much will need to be changed unless I'm really mistaken.
Today we have enough gtk+ apps that does the thing nicely. Why we want another less useful one rather a competable one? We don't really need to rush on making an app just to make it usable, do we?
I believe in incremental progresses; first have something, then improve it. Particularly in that case, where I think nothing much will need to be changed /in the application/.
> until somebody has time to play with -- because anyway it won't be a > huge modification on the API side (meaning, it could be a complex job > on the framework side, but it won't change much if anything on the > application side, if the application simply uses NSImage, which it > should). Agreed.
Ah well then if you agree with my point... :-P
One more thing, thumbnails generation, I think it is something that need serious design and thoughts. Such thing like meta data storing and etc. Or is it better to use thumb.db thing?
Well I guess we have two choices; thumbnails are metadata.. So we could work on our own metadata storing architecture (as we need one anyway), and use it for thumbnails. Or, we could use an existing metadata infrastructure... Frankly for thumbnails, the latter is probably the best approach, as a freedesktop specification already exists, and major applications already use it. It'd be stupid to recalculate the thumbnails if they already exists somewhere. So specifically for thumbnails, I'd say we should simply use the freedesktop spec, whatever it is.. Ideally our own metadata infrastructure should seamlessly integrate different "storing backend" and it wouldn't matter where the metadata is stored in our own datastores or into things like a .thumb directory. What do you think? -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams _______________________________________________ Etoile-discuss mailing list Etoile-discuss@gna.org https://mail.gna.org/listinfo/etoile-discuss
