-- iconify/lock gadgets to system ones - DONE
-- get rid of whole registration procedure - DONE
-- all icons format support - DONE for aros/os4 (morphos with ambient need different).
-- internal recognize of ELF executables the same as current 68k hunks - DONE
-- rootparent (if you go up from root dir, you will get device list, not stuck. The same as done in filler/ambient). Can be done by script currently, but will be good to just have it inbuild. - DONE
-- fix dopus_title bar: make it looks good. maybe get somehow actual title bar info to memory, and change it, to avoid mess when JAM2/JAM1 is used - DONE
ALREADY IN TICKETS:
-- long filename : currently its only 107 characters maximum, should be 255 at least.
-- 2 sets of backgrounds everywhere (to make listers looks like filler/ambient, when 2 colors is used one after one, for better and not "flat" readability).
-- add internal icons scalling. Can be as one more entry in the main Environment->Setting list (i.e. now it only Icon Display and Icon Settings, so add Icon Scalling). Or, add it to the Icon Display, if there is enough room for, as well as if we will only need ON it and set the size (and maybe algos for scalling can be different too, so user can choice one).
-- get rid of DOPUS5: assign. Low priority stuff but some if not all stuff could be accessed via PROGDIR:. However this need to be examined carefully to not break anything.
** TODO **
-- mouse wheel support everywhere (prefs and co where non system scrollbars in use).
-- replace all the scrollbars, arrow-gadgets and all "ugly" parts where possible on system ones.
-- support of hi-color images for toolbar
-- bubble helps for buttons and some other places
-- get rid of whole patching at all. If it not possible to remove them all , then only keep those ones which 100% necessary. We also can wary patching : keep it for os3 builds, but remove that from all NG ones.
-- SFTP support in ftp.module
-- get rid of old MUFS support.
-- get rid of PENS at all as it stone-age and make no sense to limit user by that. Can be kept for os3 version through.
-- Add options in the Environment/Lister Options, for "open in new lister" behaviors, and there should be something like:
1.nameofoption:"keep old one as dest"(asitnow,andoptionshouldbetheresousercanchoiceoldwayornewone).I.e.oldlisterwillbeasdest,andnewonemeantobesource.Asitrightnow.2.keepoldoneassource(anotherwayaround).I.e.oldlisterwillkeepsassource,andnewonewillsettodest.
-- if there is only 2 listers on screen, and none of them set to Dest, then when we choice something to copy in any of them, set another one as Dest automatically. I.e. when you only have 2 listers open and while one is src and another one "off", then instead of popping up the select destination window, automatically set the off window to dest. Of course if it not "devicelist" , as it always should be OFF.
Last edit: kas1e 2014-05-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We probably could try to use ticket system for feature requests and enhancements. I have not used this ticket system here but looks similar to bugzilla.
Some of features are fairly easy and some need quite lot coding like bubble helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Ikka
I assume even "2 sets of backgrounds everywhere" should be not the harder part. Now, where we go to the Environment/ListerColours and press "Modify" on any of the itens, then we have just 2 palettes for Background and Foreground. I assume we can just double that part, and add in the same window the same 2 palettes but call them Background2 and Foreground2. Only to be checked what to do in code of lister and how to get them right
Imho hardcore ones are buble-helps and icons ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Adding more gadgets to window is not necessarily trivial. It is easy when you are using GUI toolkit with built-in layout engine (like MUI or Reaction) but DOpus is using some custom layout engine and it takes some time to figure out how things work.
Icons need some new code and we have to examine different paths to reach that goal... parsing icon data is not that difficult. Bubble helps are certainly "hardcore" stuff. But it remains to be seen if existing DOpus code can be used there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
get rid of DOPUS5: assign. Low priority stuff but some if not all stuff could be accessed via PROGDIR:. However this need to be examined carefully to not break anything.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Works ok, but of course dunno it it will cover all the cases correct. For example there some "mouse buttons over inactive windowses" option, dunno what it mean.
Last edit: kas1e 2013-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Currently if we tryed to run dopus5 again while it already running, we have a window like "Directory Opus appears to be already running ! Running a second copy has the potential to cause problems, and it is recommended that you do not"
And give 2 buttons: "chancel" and "run again". If we will choice "run again", its indeed in most cases just will crash and burn. It will conflicts with forbit/permits and all the stuff.
So, my suggestion for improvements its just put there one single button in the middle of window "Ok, do not run it". So it will be never 2 copy at one time, and what is most important, users will see no crashes and does not matter what they do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
There's nothing really wrong with the copy routines. When links are encountered, the file that the link points to is copied. That's how most copy programs & commands deal with links. Copying the actual "link" gets complicated. I think "hard" links only work on the FFS filesystem so a program would need to check what filesystem is used for the destination before copying and then throw up a requester asking the user if the actual file should be copied, skip the link or change the link to a "soft" link in the destination.
You also have the issue of where the copied link should point. For backups, you might want to copy the link "as-is" so it will remain the same when you restore the backup. If you are copying a link to another location on your hard drive, do you want the copied link to point back to the original link, back to the original linked file or to a copied destination file? Copying links with OS4 is even more problematic since links are automatically resolved.
Dopus5 copies the file a link points to, just like the AmigaDOS Copy command and Dopus4. Since Dopus5 doesn't even fully work yet, I think it's a little premature to be worrying about new features.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@all
I update first post : now we have new gadget in main listers, no register.module and new native icons (for aros and aos4, on morphos there seems need some different code because of ambient).
Last edit: kas1e 2013-09-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@All
I start one by one adding all of this to tickets, so once i will done we can just delete that thread, and works in terms of bug-reports and feature-requests just from tickets. Imho will be easy for everyone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@All
I do more todo/feature requests into tickets , but for 5.91 (so they will wait after stable 5.90 done). I.e. all those which are for 5.91 can be skips for now, to avoid us to be forever on pre-release stage.
Last edit: kas1e 2013-10-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@kas1e
All the feature requests make it difficult to find things that need to be fixed (bugs). The admin docs state that there can be more than one tracker for different purposes. Could you add a seperate tracker for feature requests so that we can easily see what needs fixed. The users will keep adding feature requests until Dopus5 becomes a robot that makes their breakfast and tucks them into bed at night :-) It just creates confusion when I'm trying to find something I can fix. If naming the trackers is an issue you can call the bug tracker "Issues" or "Problems" and the other one "Requests" or "Feature Requests".
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@Xenic
Done. Now in tickets we have 2 groups: Bugs and Feature Requests. In them there 5.90 and 5.91 milestones. I regroup everything, so in all groups all sets for right milestones now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DONE:
-- iconify/lock gadgets to system ones - DONE
-- get rid of whole registration procedure - DONE
-- all icons format support - DONE for aros/os4 (morphos with ambient need different).
-- internal recognize of ELF executables the same as current 68k hunks - DONE
-- rootparent (if you go up from root dir, you will get device list, not stuck. The same as done in filler/ambient). Can be done by script currently, but will be good to just have it inbuild. - DONE
-- fix dopus_title bar: make it looks good. maybe get somehow actual title bar info to memory, and change it, to avoid mess when JAM2/JAM1 is used - DONE
ALREADY IN TICKETS:
-- long filename : currently its only 107 characters maximum, should be 255 at least.
-- 2 sets of backgrounds everywhere (to make listers looks like filler/ambient, when 2 colors is used one after one, for better and not "flat" readability).
-- add internal icons scalling. Can be as one more entry in the main Environment->Setting list (i.e. now it only Icon Display and Icon Settings, so add Icon Scalling). Or, add it to the Icon Display, if there is enough room for, as well as if we will only need ON it and set the size (and maybe algos for scalling can be different too, so user can choice one).
-- get rid of DOPUS5: assign. Low priority stuff but some if not all stuff could be accessed via PROGDIR:. However this need to be examined carefully to not break anything.
** TODO **
-- mouse wheel support everywhere (prefs and co where non system scrollbars in use).
-- replace all the scrollbars, arrow-gadgets and all "ugly" parts where possible on system ones.
-- support of hi-color images for toolbar
-- bubble helps for buttons and some other places
-- get rid of whole patching at all. If it not possible to remove them all , then only keep those ones which 100% necessary. We also can wary patching : keep it for os3 builds, but remove that from all NG ones.
-- SFTP support in ftp.module
-- get rid of old MUFS support.
-- get rid of PENS at all as it stone-age and make no sense to limit user by that. Can be kept for os3 version through.
-- Add options in the Environment/Lister Options, for "open in new lister" behaviors, and there should be something like:
-- if there is only 2 listers on screen, and none of them set to Dest, then when we choice something to copy in any of them, set another one as Dest automatically. I.e. when you only have 2 listers open and while one is src and another one "off", then instead of popping up the select destination window, automatically set the off window to dest. Of course if it not "devicelist" , as it always should be OFF.
Last edit: kas1e 2014-05-12
We probably could try to use ticket system for feature requests and enhancements. I have not used this ticket system here but looks similar to bugzilla.
Some of features are fairly easy and some need quite lot coding like bubble helps.
@Ikka
I assume even "2 sets of backgrounds everywhere" should be not the harder part. Now, where we go to the Environment/ListerColours and press "Modify" on any of the itens, then we have just 2 palettes for Background and Foreground. I assume we can just double that part, and add in the same window the same 2 palettes but call them Background2 and Foreground2. Only to be checked what to do in code of lister and how to get them right
Imho hardcore ones are buble-helps and icons ?
Adding more gadgets to window is not necessarily trivial. It is easy when you are using GUI toolkit with built-in layout engine (like MUI or Reaction) but DOpus is using some custom layout engine and it takes some time to figure out how things work.
Icons need some new code and we have to examine different paths to reach that goal... parsing icon data is not that difficult. Bubble helps are certainly "hardcore" stuff. But it remains to be seen if existing DOpus code can be used there.
TODO
@ikka
Right, added to first post
Mouse wheel works in OS3 and MorphOS. Magellan uses NEWMOUSE standard where mosue wheel events are encoded as rawkey events.
@Ikka
Yep, mouse-wheel mostlu is os4 related todo, i already have all necessary code, should be no problems to add it.
But from another side, as i can see, mouse-wheel didn't works even on morphos for example in "prefs", windowes.
@Ikka
I added mouse-wheel-os4-native support for main listers at least:
Works ok, but of course dunno it it will cover all the cases correct. For example there some "mouse buttons over inactive windowses" option, dunno what it mean.
Last edit: kas1e 2013-04-29
@all
Currently if we tryed to run dopus5 again while it already running, we have a window like "Directory Opus appears to be already running ! Running a second copy has the potential to cause problems, and it is recommended that you do not"
And give 2 buttons: "chancel" and "run again". If we will choice "run again", its indeed in most cases just will crash and burn. It will conflicts with forbit/permits and all the stuff.
So, my suggestion for improvements its just put there one single button in the middle of window "Ok, do not run it". So it will be never 2 copy at one time, and what is most important, users will see no crashes and does not matter what they do.
@all
There was one report from Billt on amigas.net:
I assume there can be something wrong with copy routines then ? (or even maybe patching).
@kas1e
There's nothing really wrong with the copy routines. When links are encountered, the file that the link points to is copied. That's how most copy programs & commands deal with links. Copying the actual "link" gets complicated. I think "hard" links only work on the FFS filesystem so a program would need to check what filesystem is used for the destination before copying and then throw up a requester asking the user if the actual file should be copied, skip the link or change the link to a "soft" link in the destination.
You also have the issue of where the copied link should point. For backups, you might want to copy the link "as-is" so it will remain the same when you restore the backup. If you are copying a link to another location on your hard drive, do you want the copied link to point back to the original link, back to the original linked file or to a copied destination file? Copying links with OS4 is even more problematic since links are automatically resolved.
Dopus5 copies the file a link points to, just like the AmigaDOS Copy command and Dopus4. Since Dopus5 doesn't even fully work yet, I think it's a little premature to be worrying about new features.
@all
I update first post : now we have new gadget in main listers, no register.module and new native icons (for aros and aos4, on morphos there seems need some different code because of ambient).
Last edit: kas1e 2013-09-18
@all
Add two more feature requests related to listers.
@All
I start one by one adding all of this to tickets, so once i will done we can just delete that thread, and works in terms of bug-reports and feature-requests just from tickets. Imho will be easy for everyone.
@All
I do more todo/feature requests into tickets , but for 5.91 (so they will wait after stable 5.90 done). I.e. all those which are for 5.91 can be skips for now, to avoid us to be forever on pre-release stage.
Last edit: kas1e 2013-10-29
@kas1e
All the feature requests make it difficult to find things that need to be fixed (bugs). The admin docs state that there can be more than one tracker for different purposes. Could you add a seperate tracker for feature requests so that we can easily see what needs fixed. The users will keep adding feature requests until Dopus5 becomes a robot that makes their breakfast and tucks them into bed at night :-) It just creates confusion when I'm trying to find something I can fix. If naming the trackers is an issue you can call the bug tracker "Issues" or "Problems" and the other one "Requests" or "Feature Requests".
@xenic
yeah, will restructure its all tomorrow
@kas1e
O.K. Thanks.
@Xenic
Done. Now in tickets we have 2 groups: Bugs and Feature Requests. In them there 5.90 and 5.91 milestones. I regroup everything, so in all groups all sets for right milestones now.
Would it be possible to choose which gadgets appear?
Would it be possible to have a native AROS 68k build?