Personal Video Database
English => Feature Suggestions => Topic started by: downe on April 25, 2010, 09:48:14 am
-
This is a great program, but a few things for me would be perfect...
When I look on filmography of some actor, and click on movie which I don't have, program automatically adds that movie in the list in the left window... I don't understand why it does that, is that a bug, or how to detain that?
Also, today with big monitors, and big resolutions, for me is important to have possibility to increase font size in right window, not only in left window....
Also I like screenshots in my database, but it's very tiring every time to double click on some screenshot, for me it's better to have option for single left mouse click to display screenshots.... And would be nice to have possibility to zoom window with screenshot...
best regards
-
The link behaviour is configurable at Preferences - Miscellaneous.
Font sizes and all aspects of the movie and people information panels are completely configurable in the skins (http://www.videodb.info/help/hlp_skins.html).
Double-clicking is tiring? That's sad... ;)
Single clicks are already used to switch between posters and I kind of like it. I plan to implement a full featured viewer in the next major release.
-
First, I want to thank for the support for big monitors and high resolutions!
When I look on filmography of some actor, and click on movie which I don't have, program automatically adds that movie in the list in the left window... I don't understand why it does that, is that a bug, or how to detain that?
The proper question for oneself here would be IMHO, what does one want by clicking on a movie link the one doesn't have?
The third question is already considered by nostra in a way to add next/previous image button while previewing all images, not only screenshots.
Cheers
-
Ok, thank you for the answers, I didn't know that most of these things is already implemented...
And "a full featured viewer" would be fantastic :)
-
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.
As far as that goes, having (say) 5 font settings (1-5, with 3 being default), a skin coder could do something like:
<font id=1/> and user settings (color / boldness / italics / underline / typeface) could be taken from the the appearance dialog. Naming the numeric sequence (small, link, link_visited, normal, subtitle, title) instead of numbering would clarify for the user, what exactly they were changing.
This logic could be extended to globally configure <section> colors, speed buttons, rating images and other such things (skin background image, PVD info pane background image), separator images, which columns to display in filmographies, selection of an external viewer for images...it goes on and on...an option to display an image with a link...set sizes for screenshots and posters.
The only drawback I can think of is when a user likes the whole appearance of a skin, but doesn't have the APPEARANCE settings to accommodate this. This would require the setting of defaults in the skin that could be overridden by the appearance settings (ie. "use skin defaults" | "user skin settings"), or an external file that is included with a skin and loaded automatically by PVD. Now that PVD scripting supports files, it may be possible to write a script that does inline conversions and rewrites the skin....hmmm...might have to try that...
-
Some interesting ideas, but I have reservations. Skins are difficult enough to create without having to accommodate dynamic attributes. Normally, even the choice of font size has to be in balance with column widths and other layout considerations. Font colours have to go with background colours. Some of the same considerations could be applied while changing "appearance settings," but because finding alternate combinations of settings that "work" would probably require the settings be saved—by skin. If that's not complicated enough, then what about the user who is not familiar with skinning, and assumes any combination of appearance settings should work?
There is a viable alternative to this. A well constructed and documented skin is not difficult to modify to reflect preferences in font's, colours, etc. Different variations of the same skin can simply be saved as separate skins. Perhaps the biggest problem with the idea of appearance settings is most users would want and expect them to work. The sad truth is that modifying the skin, as intimidating as that may seem, is the only thing that always works. Providing appearance settings would only make it less likely users will make the effort to do so.
-
If that's not complicated enough, then what about the user who is not familiar with skinning,
I agree. I torture myself to put (display) year in brackets, yet...
-
All that's needed to ensure a font is visible is to not allow fonts to have the same color(s) as sections. There are lots of ways to set a 'minimal difference' that would ensure good visibility...or more likely a message box warning about the intended color change. To my knowledge, this isn't implemented in PVD itself, and I haven't seen many support queries about displaying black fonts on a black background. It's sort of obvious hard to miss seeing the difference.
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. Besides, my eyes aren't getting better as I get older, and it would be much more convenient to set the font sizes once in one place than do global string replaces in a skin file. People are more intimidated changing programs than changing selection boxes. The number of script update requests is proof enough that there is an intimidation factor.
Actually, with more thought, all that's needed to display a skin in a web browser is an XSL file (not exactly true...the xml from PVD isn't really browser compliant...but it's easy enough to fix). This means that a proper XSL file would allow the creation / editing of skins via an external app, which would probably be even better (if more people were familiar with such programs). Similarly xml files could be displayed via a custom xsl file that would provide <href> links around fonts and sections, allowing users in an HTA to set fonts / colors in real time without changing the original file...until they were ready to do so (not exactly trivial programming, but not rocket science either).
-
I agree. I torture myself to put (display) year in brackets, yet...
You mean like in this skin?
PVD VinT_1680p
-
Exactly mgp. But, it looks pretty ugly while it seems that there were unnecessary extra spaces after opening, and before closing bracket. Don't you think so?
-
Now you know why I don't use brackets <grin>.
SPACE="0" is your friend...not sure if it goes on the column, label or caption, but it will eliminate the spacing issue.
-
The fact that skins are designed to be displayed at a specific resolution is a failing in the skin system...
Perhaps is should be a browser system, perhaps it should not—I don't know. But it isn't. And I doubt we can expect the skinning system to be replaced any time soon.
But, it looks pretty ugly while it seems that there were unnecessary extra spaces after opening, and before closing bracket.
In the same vane... The system was not designed to do what the skinner was trying to make it do. Unless the ugly result is what you want—then it worked perfectly. I don't understand the need to make something do something it wasn't intended to do, and then complain about the results. There's lots of other ways to display the same information effectively.
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. ;)
-
I think a concatenate function would be the appropriate tool for this situation
And I want "explode" ;D. Not really.
-
mgp,
Indeed, space was my friend. So as you, I'd dare to say. ;)
The system was not designed to do what the skinner was trying to make it do.
In order to reply on this one, I need to be clarified what "system" is in the matter.
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.
Well, concatenating is one of my favorite functions. So obvious, so logic, so natural as adding is, for instance. But, it is so, while in Excel. Since don't know anything about xml, except common sense, now you know why I didn't use the function - haven't seen it in any xml. And, I'm always open minded for further illuminations, and the three of you are my main illuminates.
So, shoot, you know you never spend more than two bullets on me. ;)
-
So, shoot, you know you never spend more than two bullets on me.
Since mgp is here, I think it would be more fitting to say, "I don't want to talk to you no more, you empty headed animal food trough wiper. I fart in your general direction." ;)
-
Time to:
Welease Woger the wobbah !!!
-
Wow, please don't overrate my knowledge of English. I'm confused again! Did I offend you rick? Or, am I in the middle of something else?
Whatever I wrote on this topic was meant to be affirmative on you guys.
-
Wow, please don't overrate my knowledge of English. I'm confused again! Did I offend you rick? Or, am I in the middle of something else?
Whatever I wrote on this topic was meant to be affirmative on you guys.
English humor is a weird beast. Rick was quoting a line from "Monty Python & the Holy Grail"...similar to my signature in the sense my signature isn't intended to offend.
-
Did I offend you rick?
No. Nor do I expect you to understand why Woger was not a pick-pocket. ;D
-
I went postal for a moment, that's for sure.
-
The fact that skins are designed to be displayed at a specific resolution is a failing in the skin system...
Perhaps is should be a browser system, perhaps it should not—I don't know. But it isn't. And I doubt we can expect the skinning system to be replaced any time soon.
PVD supports XML and hyperlinks...if it walks like a duck... I think you're being overly dramatic suggesting I want a whole new skinning system. All I asked for was horizontal information pane scrolling when there is a text overflow (which there are good reasons to discount, but I discount them :) ).
I dislike having things squished into the available space (sometimes by truncating ie. single line text fields, sometimes by expanding to extra display lines ie. genres, and sometimes to concatenating lines ie. genres ). In particular, the truncation of a person's filmography information is very irritating to me, since both the title and original title are truncated equally. Given that a skin may be altered to provide 'ease of use' features (ie. big fonts), current data hiding methods don't really provide a solution.
It's simple priorities to me. Is the display format more important than the data itself? If so, I'm offbase (who could guess a database application might consider it's data of secondary importance?), in which case my suggestion becomes that truncation of displayed data be eliminated (which will require much more code than adding horizontal scrolling).
-
Concatenate two monitors horizontally, et voila! ;D
-
I think you're being overly dramatic suggesting I want a whole new skinning system.
I don't think so. I was responding directly to what you said... "Actually, with more thought, all that's needed to display a skin in a web browser is an XSL file (not exactly true...the xml from PVD isn't really browser compliant...but it's easy enough to fix)." It's obvious your specific complaints could be addressed within the current system, but it seems you'd rather make the point the fundamental nature of the display system should be different.
There are also much simpler solutions if the limitations of the current system are respected. Information truncated in a short text field would not be in a long text or memo field. It shouldn't be necessary to make the skin system adapt to data stored in an inappropriate field type. But I suppose there are exceptions to that rule—the data growing beyond what the field was originally meant for, or users using the field for something different. To accommodate these situations, a skin function that transforms data from one type to another is surely feasible.
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.
Concatenate two monitors horizontally, et voila!
I think we're going to pay for having exposed this guy to Monty Python. ;)
-
I think we're going to pay
Nuh, that one was on the house ;)
a skin function that transforms data from one type to another is surely feasible.
I'm not sure I understood this?
-
I'm not sure I understood this?
A skin function that would, for example, display data from a short text field as if it came from a long text field—so it won't be truncated.
-
Oh, ok. For a moment it sounded to me like the data itself to be transformed, from numbers to text, for instance, etc...
-
My quote in context is more appropriate. I was discussing the possibility of creating xml skins from a WYSIWYG development environment.
-
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.
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.
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.
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.
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
I'll think about it, but there some problems here: different field types and edit mode...
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.
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.
I was discussing the possibility of creating xml skins from a WYSIWYG development environment.
I will be glad if you write such an editor, really ;) ::)
-
I will be glad if you write such an editor, really ;) ::)
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.
-
I'll think about it, but there some problems here: different field types and edit mode...
Oh, so that's what mgp meant...
And I want "explode"
...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 -> ?).
I could embed internet explorer pretty easily for such fields some time later...
How about anything but IE?
-
How about anything but IE?
IE is the only one that I know for sure that its working good and easy to implement. There should be a possibility to use Mozilla engine as well, but I do not know how difficult it is to embed.
-
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.
Hm, looks promising. I will give it a try on occasion.
-
The HTML Delphi control uses the default browser...if I remember correctly.
Note: The scrolling behavior I was suggesting was for the whole page, not individual fields. Scrolling the whole screen would be easier to implement that scrolling individual fields, and, as mentioned, multiple scrollbars within the page doesn't look good at all.
-
he HTML Delphi control uses the default browser...if I remember correctly.
No, it is IE, IMHO
Note: The scrolling behavior I was suggesting was for the whole page, not individual fields. Scrolling the whole screen would be easier to implement that scrolling individual fields, and, as mentioned, multiple scrollbars within the page doesn't look good at all.
OK, this changes the story dramatically. I can actually add the suggestion to my TODO List.
-
No, it is IE, IMHO
Ooops, right you are. http://delphi.about.com/b/2005/01/15/using-firefox-instead-of-twebbrowser-in-delphi-applications.htm unfortunately, there would be someone using Opera or Lynx or ... whatever. Scratch that idea.