• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Replacement of system File Open Dialog

Started by EugeneGorbunoff, 2010.07.11, 18:52:42

Previous topic - Next topic

EugeneGorbunoff

http://www.os2world.com/content/view/20047/2/
QuotePosted by Eugene Gorbunoff - Friday, 09 July 2010


One more up. .. .

Does anybody have problems with old IBM applications? Or FOC is transparent and works fine?


RobertM

#1
Looks gorgeous, havent had a chance to test it. Will be a little while still before I can get a new subscription and access to the betazone. When I do though, I will let you know (I've got a lot of old OS/2 apps lying around or still in use).

Question: how does it affect apps that draw their own, such as MED and PMView?

Suggestion: VERY minor, but for GUI "flow" I'd suggest moving "OK" and "OTMeHa" (not sure what that is in English) to the right side so things flow top left to bottom right - or center them. Again though, very very minor suggestion.

Best,
Rob


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


abwillis

Quote from: RobertM on 2010.07.11, 21:25:06
Looks gorgeous, havent had a chance to test it. Will be a little while still before I can get a new subscription and access to the betazone. When I do though, I will let you know (I've got a lot of old OS/2 apps lying around or still in use).

Question: how does it affect apps that draw their own, such as MED and PMView?

Suggestion: VERY minor, but for GUI "flow" I'd suggest moving "OK" and "OTMeHa" (not sure what that is in English) to the right side so things flow top left to bottom right - or center them. Again though, very very minor suggestion.

Best,
Rob
I did a bit of testing here.  It turns out very few apps I am using are using the standard file dialogs instead of their own.  Those using their own are not affected.  I need to check the docs to find where to report it but it caused a crash in Lotus Word Pro when using the file open dialog (not the initial launch screen).
Andy

Saijin_Naib

Ugh, can the 8-color icons not be used in that dialog?

RobertM

Quote from: Saijin_Naib on 2010.07.12, 02:25:58
Ugh, can the 8-color icons not be used in that dialog?

In the titlebar area? They look fine to me... though I'm not one would sacrifice system resources for going up to 32bit icons. One can probably change them using the resource compiler tools if one wanted to...


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Saijin_Naib

No, within the File Control itself (in the Tree View & the List View).

If your objective is to make the UI more up to date, keeping 8 color icons and file controls is sort of counter to the stated purpose.

RobertM

Quote from: Saijin_Naib on 2010.07.12, 03:08:54
No, within the File Control itself (in the Tree View & the List View).

If your objective is to make the UI more up to date, keeping 8 color icons and file controls is sort of counter to the stated purpose.

Four guesses... (there could be other reasons)

(1) They are using the smallicon value that the test system has for each object (in which case, it will default to whatever it is) and thus are getting those 16 color icons.

(2) They are calling/requesting the smallicon value and image from a DLL that still has the original OS/2 icons from "back in the day" - in which case that's what's being displayed

(3) (Similar to #1) They are using the smallicon value that the test system has for each object - BUT (the part different than #1) picking the icon value for different resolution/color depth than what the system is actually using. When I used to make my own custom icons for Warp by modifying the existing ones, I found that each object (folders, programs, etc) had 7 to 10 icons stored for it. Those include XGA/8514 16 color, XGA Small Color Form (same as the previous one but 20x20 pixels for stuff like the tree view and folder small icon views) and others (including black and white).

(4) For simplicity sake, or whatever reason, any DLLs associated with this are using OS/2's original, standard smallicon set - all of which were 16 color icons.

OS/2 does not have 8 color icons. Though you may only find 8 colors in the icons used, the only choices it supports are the standard bitmap formats of 2 color (BW), 16 color (for XGA and std VGA mode), 256 color and RGB (24 bit). While this varies with the new PNG icons, I suspect that 8 colors is still not an option.

Regardless, (and assuming that the sizes in the screenshot are the only sizes usable, instead of full sized icons), with a little work and using the full 16 color palette, one could pretty easily make small icon sets that are near indistinguishable from their higher color large icon brethren. After all, the color palette can be remapped. I used to do that by importing the particular large icon into PMView, resizing it to 20x20 (or whatever mini-icon size I was using), converting it to 16 color, putting it back into the icon editor and cleaning it up (which usually mostly consisted of recreating the transparency areas, since the resizing would change pixel colors of that area from the needed value of 127, 255, 127 (RGB).




Anyway, without being able to test it, not sure if it's something as easily changeable as having an OS/2 or eCS setup that has pretty small icons for each object.

I DO know on the systems I have, where I have taken the time to customize the small icons, and remove the 16 color versions of them, it has forced OS/2 to pick the 256 color or true color smallicon versions. I also know that without good video card support (ie: your video card is stuck using VESA mode and the card poorly supports that, making everything graphics related crawl), it's not a good idea.

When I havent made custom small icons for the stuff (and removed the 16 color versions) I have found that various apps and such that call for those icons default to the "lowest common denominator" - namely the 16 color ones.


Quote from: Saijin_Naib on 2010.07.12, 03:08:54
If your objective is to make the UI more up to date, keeping 8 color icons and file controls is sort of counter to the stated purpose.

This part I disagree with. The biggest problem with the OS/2 File Dialog isn't lack of fancy colors. It's lack of functionality (due to it being a remnant from the original Microsoft GUI components). With all the work they did on the WPS, it's something I was always amazed that they did NOT replace. It should have died with OS/2 1.3 and not been carried forward.

As an example of lack of functionality:
* It does not support drag and drop (again, because of it's roots - it's not a full object container in the sense the rest of the OS is).
* It does not support resizing
* It does not support sizing
* It still uses the very limited Windows and OS/2 1.3 filter method
* It does not support multiple views (details, icon, tree, etc) - again because it isnt fully object enabled and is a horrendous holdover
* It does not support object previews
* It does not support any right click operations (which if it were fully object oriented, it would - in the same fashion any desktop icon does)
* It does not support auto-refresh (again, due to the lack of obect oriented aspects in it)

There are probably more functionality things that are lacking... but you get the point. Fixing those things (which seem to be in this new endeavor) are far more important than how many colors the icons are. If your car doesnt have an engine, it really doesnt matter how pretty it is. And again, the OS/2 File Dialog box is and has virtually always been, one of the ugliest and least functional parts of OS/2 since V2 came out. The only thing I can think of off the top of my head that competes with it is MPTS - which is yet another holdover from Microsoft's OS/2 v1.3 and Windows GUI - it too should have died a long time ago.

Best,
Robert



|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Saijin_Naib

Certainly the aesthetics of the control dialog aren't the only thing lacking. I've previously suggested something more akin to the Windows or XFCE file dialog and got flamed out about M$ fanboy this and that and other (seemingly) requisite bullshit.

Seeing as I've already fought that battle, I figured I'd just comment on how its just simply ugly right now.

Pair that up with Eschemes, PNG Icons/Sunny Icons, etc and you have something that will look out of place if all it uses are the standard ugly 16 color icons. That is all I'm saying.

RobertM

#8
Quote from: Saijin_Naib on 2010.07.12, 04:30:46
Certainly the aesthetics of the control dialog aren't the only thing lacking. I've previously suggested something more akin to the Windows or XFCE file dialog and got flamed out about M$ fanboy this and that and other (seemingly) requisite bullshit.

Seeing as I've already fought that battle, I figured I'd just comment on how its just simply ugly right now.

Pair that up with Eschemes, PNG Icons/Sunny Icons, etc and you have something that will look out of place if all it uses are the standard ugly 16 color icons. That is all I'm saying.

If I get around to testing it, I will let you know if it actually truly uses 16 color bitmaps (ie: resources in a DLL), or is simply defaulting to the icon set on the test system used for the screenshot (in which case, on a couple of my systems, it can only default to 256 color small icons and should be very pretty).

As an example, I've got the REXX integration (DnD and more) support added to Firefox. When I start FileZilla, it loads my small icons - not the original ugly ones.




Dunno about the XFCE file dialog, but I think the problem with duplicating the Windows one is:
(1) lack of functionality (object support)
(2) interface inconsistencies
(3) limited display/interface options (tree view?)

The idea of implementing one that has more of the features that are in the Windows one (but done properly by making it object oriented) though, is a good one. Possible your posts were misconstrued. Or possible you worded it as porting the Win dialogs to OS/2? (dunno - hence it's a question) - which would be a step nowhere since it's highly kludge oriented with no real object technology behind it.

Just so you know, it's not a debate about what's better - the OS/2 File Dialog is even worse when it comes to functionality - regardless of how Microsoft implemented their replacement dialogs. At least they managed to make something more functional. IBM seriously dropped the ball on this one, and I dont know why.

Currently, I use xFile on my primary OS/2 systems... it's ugly, but very functional. I'm that disgusted with the original OS/2 one.

Best,
Rob


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Saijin_Naib

#9
Here is the standard Win File Open/Save dialog.

You have the standard window navigation controls (previous/next folder history).
You have the standard URI bar (here, Breadcrumb style).
You have the standard File System Index/Journal search field.
You have the Organize Button (replaces standard File text Menu, as well as enable Details Pane).
You have the standard New Folder button (or right click -> New -> Folder)
You have the standard File System Tree view.
You have the View options button (Extra Large Icons, Large, Medium, Small, List, Details, Tiles, Content).
You have the Preview Pane toggle.
You have the help button.

I don't see what is lacking in the functionality of this dialog. I never suggested straight porting of Win code, merely that this dialog (IMO) is incredibly functional and flexible. What I suggested then as now is that something akin to this dialog would be VERY useful. Even if we never get a proper Index service, simply having the OS/2 Search command built into the dialog could prove pretty helpful.

That is all.

RobertM

Quote from: Saijin_Naib on 2010.07.12, 08:32:10
Here is the standard Win File Open/Save dialog.

You have the standard window navigation controls (previous/next folder history).
You have the standard URI bar (here, Breadcrumb style).
You have the standard File System Index/Journal search field.
You have the Organize Button (replaces standard File text Menu, as well as enable Details Pane).
You have the standard New Folder button (or right click -> New -> Folder)
You have the standard File System Tree view.
You have the View options button (Extra Large Icons, Large, Medium, Small, List, Details, Tiles, Content).
You have the Preview Pane toggle.
You have the help button.

I don't see what is lacking in the functionality of this dialog. I never suggested straight porting of Win code, merely that this dialog (IMO) is incredibly functional and flexible. What I suggested then as now is that something akin to this dialog would be VERY useful. Even if we never get a proper Index service, simply having the OS/2 Search command built into the dialog could prove pretty helpful.

That is all.

Agreed on all of them. Sadly, the lack of many of those is the reason I run xFile. It has all of those features except Search, selectable view for the file list (ie: icon, list, etc), sort and Preview (instead, it has a "File Viewer" option that will call the default program - though that can be customized to call another program that instead displays a preview - kinda a kludgy way of doing things). It (xFile) also isnt object oriented - and in this respect, Windows (regardless of the method) has come a long way.

Best,
Robert


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


Fr4nk

I think a new file dialog is absolutely worth developing for.

I believe the control has not being changed in past because the idea was not to use this kind of dialog but use the WPS. Open objects from a WPS folder instead using file dialogs. I think generally the file open dialog is a relict from file- and application oriented thinking. BUT users had always the problem to handle large amounts of files with WPS - last but not least because WPS has some bugs and missing features (for instance blowing up ini files after heavy use of WPS with lot of files, or the problems with light tables, missing progress bars etc.pp.).

Unfortunately I can't test the new dialog because I use eCs 1.2 without subscription and I don't want touch my running system. Maybe it could be avi as a add-on for eCs 1.2 users aswell, this would be nice.

melf

I've tried the new dialogue for some week now and find it to be a big improvement in usability. I appreciate the flexibility that the file-tree to the left gives, more dynamic than the original. The preview for the moment just shows pictures - and docs supported by the wps-add on for OO. I don't know how far this could be developed.

The new dialogue is hopefully more tempting to use for programmers - as abwillis pointed out, many programs have their own dialogue. Not unimportant, I think, it is also nice for the eye.
/Mikael