#1
|
|||
|
|||
v3.2 changes: request for clarification
Dear Kinook,
can you please comment on these changes please... 1) Show combined note text for multiple selection if related option is enabled. What is new about this feature? 2) Options to increase import/update performance: - why did you decide to have this done via going to registery vs. GUI options dialogue? 3) Quick access to toggle common option... - even though welcomed, I still think there is a better more efficient way to do I learned from using NetSnippets. Why not have user push, for example, a control key (or a combination) to override whatever is set in options. 4) why did you decide to implement this feature to refresh the copy tab when switching to it vs. having UR default to opening a blank one? What is the point from duplicating an existing tab when I want to create a new one? Thank you Last edited by cnewtonne; 08-08-2007 at 10:14 AM. |
#2
|
|||
|
|||
Re: v3.2 changes: request for clarification
Quote:
Quote:
Quote:
http://www.kinook.com/UR/Manual/customizekeyboard.htm |
#3
|
|||
|
|||
sorry, I had re-edit my post to add this question ...
4) why did you decide to implement this feature to refresh the copy tab when switching to it vs. having UR default to opening a blank one? What is the point from duplicating an existing tab when I want to create a new one? Also, being able to select import location is working fine with Firefox, global key, but NOT with OL? Can you please confirm on your end |
#4
|
||||
|
||||
Re: v3.2 changes: request for clarification
Quote:
|
#5
|
|||
|
|||
it really boils down to this same logic browsers have i.e. to start a new content in a new tab. This is very different from duplicating a tab. For some reason, UR combined these 2 together and IMHO, they should be separated. It is risky and when you have 10 tabs open on average that way I do, you end up editing same item in multiple places without knowing. Yes, with the change in 3.2, tabs now refresh, but why even go there? Just let me either ...
- start a blank one then populate it with whatever I want. - Or hold control key when clicking an item to have it start a new tab. - or anything to that effect. I did see this feature on their roadmap but seeing this change in 3.2 made me think they abandoned it. I hope not. |
#6
|
|||
|
|||
Quote:
|
#7
|
||||
|
||||
Quote:
It's probably coming from the concept, any tab has to point somewhere in the database, when you create new UR file, it has to have one item, the root, it cannot be just empty. It would probably cause problems, if tabs could be void and point nowhere, don't know, just guessing. As it is now, it opens the new tab (and points to the same item by default), you can do what you want, it's just some psychological thing ;-) that you need empty tab as you are used from browsers |
#8
|
||||
|
||||
Quote:
Just do what you wanted to do with your new tab ... |
#9
|
|||
|
|||
Quote:
Quote:
|
#10
|
|||
|
|||
OL now works with this feature enabled. Thanks
|
#11
|
|||
|
|||
Quote:
Maybe it is the psychological issue you refer to in another post &, if so, that doesn't necessarily make it un-important to the user. I mean when everything is said & done: How difficult could it be to add an alternate function & keystroke to open an empty window? |
#12
|
||||
|
||||
Quote:
|
#13
|
|||
|
|||
Quote:
|
#14
|
|||
|
|||
Difficult, actually. If it was simple, we certainly would have done it. It's a tad more involved than just opening an empty window. The change we did make fixes the problem of a tab potentially showing out-of-date information (whether opened via New Tab or other means).
|
#15
|
|||
|
|||
just for curiosity,
does it have to do with the new blank tab not having any associations or pointers to the database as was mentioned earlier? |
|
|