Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GRASS Digit: attribute window moves around not asked to #10107

Closed
qgib opened this issue Apr 3, 2006 · 7 comments
Closed

GRASS Digit: attribute window moves around not asked to #10107

qgib opened this issue Apr 3, 2006 · 7 comments
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! GRASS

Comments

@qgib
Copy link
Contributor

qgib commented Apr 3, 2006

Author Name: werchowyna-epf-pl - (werchowyna-epf-pl -)
Original Redmine Issue: 48

Redmine category:grass
Assignee: Redmine Admin


Please prevent the attribute window from jumping around

  • it often jumps to the most top-left location,
    covering the layer tree and forcing me to move it back
    from there to the location of my choice; then it will
    jump back to cover the layer tree...

Maciek

@qgib
Copy link
Contributor Author

qgib commented Apr 3, 2006

Author Name: Redmine Admin (Redmine Admin)


Is it still true?
Is it realy related to QGIS, was not it window manager problem?
I could never reproduce such a behaviour.
Does it happen also with current HEAD version?

Radim

@qgib
Copy link
Contributor Author

qgib commented Apr 3, 2006

Author Name: maciek - (maciek -)


Yes, with 0.7.4 SVN about 3 weeks old.

Is it realy related to QGIS, was not it window manager problem?

Dunno. Using Ubuntu Breezy with GNOME.

I could never reproduce such a behaviour.

KDE?

Does it happen also with current HEAD version?

Haven't tried due to lack of QT 4.1. For Breezy only QT 4.0 is
packaged, which I heard is problematic with QGIS 0.7.9.

What do I do in order to install QT 4.1 on Breezy without hacking too
much? I wouldn't mind building from source unless it is fairly
straightforward. Having qt 4.1 I could help with testing.

Maciek

@qgib
Copy link
Contributor Author

qgib commented Apr 6, 2006

Author Name: Redmine Admin (Redmine Admin)


On 4/4/06, Maciek Sieczka werchowyna@epf.pl wrote:

Yes. Easy to reproduce:

  1. Open a Grass vector.
  2. Pick "Edit table".

Do you mean 'Edit attributes'?

  1. Left click some object.
  2. Table pops up. Edit it as needed, move to lower-right corner.
  3. Click another object. All fine. Click another one - and the table
    jumps to top right corner. Bad table.

Sorry, I have no idea, the position is stored whenever the attributes
dialog is closed (deleted) and restored when a new one is created
(another element selected).
Do you have the same problem when new elements are digitized?

BTW: I have maybe similar problem with edit region dialog,
move() is called but somehow ignored.

Radim

@qgib
Copy link
Contributor Author

qgib commented Apr 6, 2006

Author Name: Redmine Admin (Redmine Admin)


I added debug output. Whenever you select an element
you should see in terminal something like

[QgsGrassAttributes]
[[QgsGrassAttributes]]::restorePosition()
wx = 200 wy = 406

The values are then used in move(wx,wy); to set windows position.
Check if these values are correct.

Radim

@qgib
Copy link
Contributor Author

qgib commented Apr 6, 2006

Author Name: Redmine Admin (Redmine Admin)


Please try with fresh SVN. I have changed widget style
and it could work. I think that the problem was that certain
widget styles calls adjustSize after move.

I have also changed it so that the window is not closed always
when a new element is selected, that should make it more pleasant.

Radim

@qgib
Copy link
Contributor Author

qgib commented Apr 9, 2006

Author Name: Redmine Admin (Redmine Admin)


Fixed in 0.8.

Radim


  • status_id was changed from Open to Closed
  • resolution was changed from to fixed

@qgib
Copy link
Contributor Author

qgib commented Aug 21, 2009

Author Name: Anónimo (Anónimo)


Milestone Version 0.8 deleted

@qgib qgib added Bug Either a bug report, or a bug fix. Let's hope for the latter! GRASS labels May 24, 2019
@qgib qgib closed this as completed May 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Either a bug report, or a bug fix. Let's hope for the latter! GRASS
Projects
None yet
Development

No branches or pull requests

1 participant