Do we get a "straight" port from MorphOS, or are you planning any OS4-specific features? The choice of GUI toolkit springs to mind as the very first thing. While MUI is generally OK with me, I do prefer (and donate more money to) projects that provide OS4's standard GUI.
Its will be just a port without any changes in the GUI. Because rewriting mui gui to reaction gui make no sense , as better to write one from scratch with new gui. Just no one will do it, while mui based app already done (+ fast, +not have problems which have amipdf). I.e. absolutly the same moment as with muiowb and with muimplayer.
@Deniil Quote:
I think AmiPDF is good enough.
Its slow and buggy.
Quote:
It has a good GUI with content table on the side, search functionality, copy text etc.
VPDF has better gui. But sure, AmiPDF gui is not that bad, just VPDF one is better organazed and more intuitive.
Quote:
Only thing I can think of is continuous page scrolling instead of this jumping between pages. Does VPDF support that?
VPDF support everything. And scrolling, and jumping.
Quote:
I think time and money can be better spent.
Its like we spend all whole days on amiga related stuff in last time :) Besides, we can't call it as "money". Its freaking few buks ! Who can call that as "money" ? I can understand if thats about few thousands at least, but few buks call "money" .. dunno. Bountys in amigaworld is mostly to be sure that users in interst to have something, and not just talks, but not about money, thats for sure.
@TonyW
Quote:
Unless VPDF can fix these problems (as well as use the native GUI, not MUI), there seems little point in spending time or money on it.
Of course VPDF didn't have those problems. Why it should crashes the same as AmiPDF ? And, its of course faster that AmiPDF in times, not just a bit (for me its one of the main point to make a port).
As for "native gui not mui", there is no point to choice beetwen, as mui progress nicely for os4, and there is no point to ask for reaction one.
Besides, those who ask for other GUI, should understand that then there is no point to port something, but just write one from scratch. But that noone will do (no time, no resource) and so we have a choice : to have a fast and efficient PDF viewer, or stack with AmiPDF for dunno how long with all our "not worth, not MUI, is it faster indeed? and co".
How much better? AmiPDF is not to slow for me except when displaying 'PDF printed webpages' generated by Google Chrome on my linux box.
Can you provide a measured benchmark?
10% would be hardly worth it 100% on the other hand....
Quote:
better usability,
That's probably going to be a matter of opinion.
Quote:
better stabilty
AmiPDF rarely crashes for me, others mileage may vary.
The important question seams not to have been asked.
Better Compatabilty
Is it more compatable with the later / latest PDF speicificatins? This is where I find issues with AmiPDF. it doesn't always recognise certain modern featurs , throwing out lists of apparent errors, although it often ends up displaying a readbable document, these slow things down somewhat.
What 'core' is VPDF based on ? And how modern is that core?
I wonder why (at least some of) those asking for a "native GUI" have not also done so for Timberwolf
Was there an option?
Quote:
MUI seems pretty "native" to me!
Sure enough. But I do feel more at home with ReAction, hence all the asking. People wouldn't ask if only kas1e had properly described what he was going to do. Submitting a lousy project proposal was his fault (and AmigaBounty's because they accepted it), not ours. People are not nagging here, they only want to know more before they decide to spend the hard-earned buck.
Someone already suggested a fresh port of poppler + Reaction GUI.
I'd much rather contribute money to this (heck, I could even help out with the GUI programming). Plus, having a native libpoppler would enable the development of other PDF-related applications.
Someone already suggested a fresh port of poppler + Reaction GUI.
There is a lot of way and suggestions. Who will do that ? When ? How fast ? Will it have bugs which will need years to be addressed ?
Quote:
Even the re-use of AmiPDF GUI might be possible.
Who will give anyone AmiPDF GUI source code ? Will authors of AmiPDF worry about all of this at all ? Is he is still alive and in interst ?
I.e. million questions, suggestions and problems with resources and time. While VPDF free, its here, and need to be "just" ported.
@Trixie Quote:
I'd much rather contribute money to this (heck, I could even help out with the GUI programming). Plus, having a native libpoppler would enable the development of other PDF-related applications.
Sounds good. Point me plz on that person who will start to works on it and when he will finish it (with or without help from anyone). Its of course ritoric and sarcastic, because we all know amiga realms.
While VPDF is here. Just need to be ported. And then anyone can again jump on hold and suggest to make a new pdf viewer, maybe, someday, if someone will find out time :)
Of course there are. There's nothing wrong with a VPDF port, I just answered broadblues question - and in that regard that someone (Geit from the MorphOS team, to be more precise) explained that wrapping an Reaction GUI around a libpoppler port isn't impossible.
explained that wrapping an Reaction GUI around a libpoppler port isn't impossible.
Why it should be unpossible all in all ? I mean, core is matter, what kind of GUI are done its only up to programmer who working with the core. Just in case with MUI we already have gui builded upon, and all the work already done by morphos author and we need only port it. But in case with Reaction we need to spend a lot more time for making the same what he do, but in reaction. Time, resources and usuall stuff.
The choice of GUI toolkit springs to mind as the very first thing. While MUI is generally OK with me, I do prefer (and donate more money to) projects that provide OS4's standard GUI.
1. For anything complex I prefer a MUI interface over a Reaction one anyday.
2. OS4 has a very good MUI anyway which is in development and getting better all the time.
3. It would not make sense if an application is working perfectly with a MUI interface to waste time converting it to Reaction (which IMHO is less versatile anyway).
pvanni wrote: And what about printing? It's there a direct turboprint support?
Doesn't AmiPDF already do this? When I open the Print window, my 2nd through 4th entries are different TurboPrint methods.
Quote:
It's possible to export pages as bitmap images? I think that a feature list is highly needed, or al least a link to a page with detailed description.
AmiPDF also does this already. Again, in the print window you can "print" all or parts of a PDF file to postscript, EPS, various JPEG and various PNG formats.
AmiPDF is unusably slow on SAM667Mhz, for example when reading Freescale P1022 reference manual (7MB in size).
I'll be donating.
- Kimmo --------------------------PowerPC-Advantage------------------------ "PowerPC Operating Systems can use a microkernel architecture with all it�s advantages yet without the cost of slow context switches." - N. Blachford
a new improved pdf reader sounds good, for me it doesn't matter if it's mui or reaction based and kas1e usually delivers so donating a few bucks to this bounty can't be bad
But in case with Reaction we need to spend a lot more time for making the same what he do, but in reaction.
That really depends on how VPDF is done. If the PDF is rendered directly in the window rastport and MUI is only used for other stuff (toolbar, sub-windows, requesters etc.), replacing it with ReAction should not be that difficult. It's a viewer so I don't expect it to have a complex GUI.
@trixie I guess what Kas1e is trying to say is that he is offering to port VPDF right *now* (while keeping the MUI interface). The question is who (if anyone) is offering to port VPDF & rewrite it's interface using ReAction, or get hold of AmiPDF source & update it's core. You? If not, then Kas1e is the only one offering their time & effort right now, so why not take advantage of it?
pvanni wrote: And what about printing? It's there a direct turboprint support?
Doesn't AmiPDF already do this? When I open the Print window, my 2nd through 4th entries are different TurboPrint methods.
Quote:
It's possible to export pages as bitmap images? I think that a feature list is highly needed, or al least a link to a page with detailed description.
AmiPDF also does this already. Again, in the print window you can "print" all or parts of a PDF file to postscript, EPS, various JPEG and various PNG formats.
Thanks,
PJS
I know AmiPDF can do those things, I am asking if also VPDF can do the same things, otherwise VPDF for me it's of no interest so I doesnt make any donation. But it seems that nobody can answer to my questions :(
The question is who (if anyone) is offering to port VPDF & rewrite it's interface using ReAction, or get hold of AmiPDF source & update it's core. You?
I've worked with kas1e before, so why not? If he gets VPDF to compile under OS4 with GCC, I'll gladly take a look at the source code and see what I can do. If it turns out to be too much work, the MUI version will always be there.
If he gets VPDF to compile under OS4 with GCC, I'll gladly take a look at the source code and see what I can do. If it turns out to be too much work, the MUI version will always be there.
Currently i have compiled it for os4 with rewriting of hooks / removing some mos specific deps and so on, and gui kind of works already. I have some problems with core (which i think should be easy to fix), as i "just for test" replace their shared cairo and some others libs(which on morphos done as native amiga libs) with simply .a stubs, and just brutally change some moments which need to fix normally.
If you in interest, then why not, it will be nice to have and mui, and reaction versions. Through seeing on code, Kiero do a lot of work even for "just" gui : 130 kb of source code for GUI only (+80kb of toolbar images which done as C arrays as well). And thats only GUI, while there is also system-related routines, which are about 100kb of source code too, and some other parts there and there. Writing the same from scratch will be a long and boring way, for sure (yep, we can keep system-related part, but 130kb of gui sources are a lot).
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
