English > Feature Suggestions

Some improvements

<< < (6/7) > >>

buah:
Oh, ok. For a moment it sounded to me like the data itself to be transformed, from numbers to text, for instance, etc...

mgpw4me@yahoo.com:
My quote in context is more appropriate.  I was discussing the possibility of creating xml skins from a WYSIWYG development environment.

nostra:

--- Quote ---Relative font sizes in the skins (ie. <font><size>+1</size></font>) would be cool.  TOOLS->PREFERENCES->APPEARANCES would seem a logical place to set a default font size for skins.
--- End quote ---

The idea is an interesting one, but I think it will be too difficult to make it work good for all skins possible, but maybe I will just implement relative font sizes with static defaults some time.


--- Quote ---The fact that skins are designed to be displayed at a specific resolution is a failing in the skin system.  Fixed sizes (pixels or point sizes) means simply that if I have a different monitor setting from the skin designer, the skin doesn't display as it was designed.  It may well be that there is text overflow when fonts are resized, but then, why can't the skin scroll as a web browser does when this occurs?  Vertical scrolling is already implemented, so that's half-way home.
--- End quote ---

I most cases you can have automatic widths and in all cases the heights are calculated automatically; horizontal scroll bars in separate fields just do not look good enough for implementing and they are in most cases not needed.


--- Quote ---I think a concatenate function would be the appropriate tool for this situation—and might otherwise be very useful—but no one has asked for it. Until now. Wink
--- End quote ---

I'll think about it, but there some problems here: different field types and edit mode...


--- Quote ---As I've mentioned a number of times elsewhere, I hope the ability to display HTML is added at some point. It would be handy for importing and displaying entire pages of data that are already formatted appropriately, displaying actual search result pages, and just providing an embedded browsing capability. I don't know whether such a thing would be a separate window, a skin function for displaying a specified URL in a memo-like HTML field, or both. I imagine doing something like that is going to beg the question, "Why not do the whole display system in HTML?" Like I said, I don't know. I do know I have no use for other movie database software that use that approach. But I don't know if that's because of limitations in the approach, or just crappy implementations.
--- End quote ---

I could embed internet explorer pretty easily for such fields some time later, but I really do not want to use a browser for skinning. As I was programming the very first version of PVD I have considered an embedded browser for information panes as many database apps do, but I quickly found out that too many problems come up and the whole flexibility is lost or even gone at all.


--- Quote --- I was discussing the possibility of creating xml skins from a WYSIWYG development environment.
--- End quote ---

I will be glad if you write such an editor, really ;) ::)

mgpw4me@yahoo.com:

--- Quote from: nostra on April 28, 2010, 12:45:27 am ---I will be glad if you write such an editor, really ;) ::)

--- End quote ---

No need to totally re-invent the wheel...  http://msdn.microsoft.com/en-us/library/ms977865.aspx  ... requires IE to be installed (not necessarily as a primary browser) and there is a check for ie6 in one of the javascript files ... just comment it out if you wish to try the program.

I bumped into this a few days ago.  I didn't really look closely at it, but suppose it could be modified to the skinning model.  I'll look at it this week and decide if it's a reasonable investment of my time.  If not, I'll see what else I can come up.

rick.ca:

--- Quote ---I'll think about it, but there some problems here: different field types and edit mode...
--- End quote ---

Oh, so that's what mgp meant...


--- Quote from: mgpw4me@yahoo.com on April 25, 2010, 10:50:35 pm ---And I want "explode"
--- End quote ---

...Yes, I suppose edit mode would have to "explode" the concatenation into it's component fields. ;)

As for different field types, you would have to do so arbitrarily based on the input fields (e.g., string + memo -> memo), and probably disallow awkward combinations (e.g., date + list -> ?).


--- Quote ---I could embed internet explorer pretty easily for such fields some time later...
--- End quote ---

How about anything but IE?

Navigation

[0] Message Index

[#] Next page

[*] Previous page