[질문] 메뉴 컨트롤에 관련된 좋은 방법을 찾습니다. 아이디어가 필요해요~ (질문을 좀 더 구체적으로 고쳤습니다.)
글쓴이: kleinstein / 작성시간: 목, 2011/05/26 - 11:34오후
어느 한 프로그램이 여러가지 기능을 제공한다고 했을때.. (예를 들어 기능 A 부터 P 까지..)
기능 A 는 메뉴 a 를 통해서 실행되고,
기능 B 는 메뉴 b 를 통해서 실행되고,
...
기능 P 는 메뉴 p 를 통해서 실행되고,
이런 식입니다.
아마 대부분 이런경우가 아닌가 싶은데요.. 이런 경우 기능 A가 실행되는 동안 기능 F 가 실행될수 없다거나 실행되어서는 안되는 경우는..
메뉴 f에 대한 선택을 금지시키거나( 기능 A가 다 실행되면 다시 기능 F에 대한 메뉴f 가 활성화 되어야 겠지요.) 사용자가 클릭해도 반응되지 않아야 하는데요..
문제는 이런 식의 상호관계가 점점 더 복잡해 질때... 보통 GUI 에서 어떻게 이런 문제를 다루는지 궁금합니다.
언뜻 생각해보게 되는게 state machine 인데요..
그러니까 각 상태별로 허락되는 메뉴와 아닌 메뉴를 구분해서 매 상태별로 메뉴를 업데이트 시키는 방법말이죠..
근데.. 이게 제게는 전혀 마음에 들지 않는 방법입니다.
너무 구식같아요..
좀 더 효율적이면서,
새로운 기능을 넣거나 뺄때에도 쉬운....
이런 잘 알려진 방법이 혹시 있는지요??
Forums:
아무도 안계신가요?
아무도 안계신가요?
질문을 좀 더 쉽게 고쳤습니다. 좋은 아이디어
질문을 좀 더 쉽게 고쳤습니다. 좋은 아이디어 있으시면 부탁드립니다~
의사결정트리?
의사결정트리?
재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.
아이디의 아이디어 무한도전
http://blog.aaidee.com
귀태닷컴
http://www.gwitae.com
데이터 마이닝에서 쓰이는 의사결정트리랑 이 문제랑 어떻게 연결이 되나요??
데이터 마이닝에서 쓰이는 의사결정트리랑 이 문제랑 어떻게 연결이 되나요??
잘 이해가 안되네요..
저도 모릅니다. 의사결정트리가 컴퓨터 시대 이전부터
저도 모릅니다.
의사결정트리가 컴퓨터 시대 이전부터 쓰이던 거 아닌가요?
제가 생각한 건 트리마다 확률이 쓰여있던 그래프입니다.
무슨 컨설팅 회사에서 나온 책에서 봤어요.
저도 잘 몰라서 물음표를 붙였습니다.
그리고 오토마타를 배운적이 없지만 오토마타는 이것과 무관한 건가요?
재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.
아이디의 아이디어 무한도전
http://blog.aaidee.com
귀태닷컴
http://www.gwitae.com
Case가 정확히 일치하는 경우는 없을 것 같긴
Case가 정확히 일치하는 경우는 없을 것 같긴 한데, 이런 방법은 어떨지?
각각의 메뉴항목에 그룹값(같은 그룹값을 가지는 메뉴는 같이 enable/disabled 된다고 가정하면)을 부여하고
Signature :) - "여유를 갖고 행동하되 게을러지지 말자"
언뜻 HSM(hierarchical state
언뜻 HSM(hierarchical state machine)이 떠오르네요.
State machine이 커질 수록 복잡성이 급격히 높아지는 데 HSM은 "state nesting"이란 개념으로 복잡성을 상당히 줄여줄 수 있습니다.
State machine을 사용할 거라면 HSM을 고려해보세요.
단점은 이해하고 적용하는데 상당한 시간과 노력이 필요합니다.
http://www.accu-usa.org/Slides/samek0311.pdf
공부해봐야겠네요.. 답글 달아주셔서 감사합니다.
공부해봐야겠네요.. 답글 달아주셔서 감사합니다.
일단 state machine 을 벗어날 아이디어는 없는것 같네요...
Observer Pattern 류의 뭔가 좀 다른 아이디어는 없을까 했는데 말이죠..
아무튼 일단 공부해보겠습니다. 감사합니다.
생각만큼 그렇게 복잡하지는 않습니다. 메뉴는 GUI
생각만큼 그렇게 복잡하지는 않습니다. 메뉴는 GUI Element이기 때문에
화면상에 보이는 메뉴가 있고 보이지 않는 메뉴 (필요할 때 나타나는, 예를 들어 파일(F) 등) 가
있습니다.
화면상에 보이는 메뉴 (툴바 아이콘등..) 같은 경우에는
보통 관찰하고자 하는 상태변수에 (예를 들어 문서가 수정 되었는가 등)
따른 callback 이나 observer 형식으로 등록되어 관찰하고 있는
값이 변할 때 같이 변하도록 해줄 수 있습니다.
같은 그룹으로 묶여진 툴바 전체를 enable/disable할 수도 있겠지요.
눈에 보이지 않는 메뉴, 즉, 맨 위의 파일(F), 편집(E) 와 같은 메뉴를
눌렀을 때 아래에 나타나는 메뉴나, 필요한 경우 마우스 오른쪽버튼을 눌러서
나타나는 메뉴등의 경우에는, 메뉴가 화면에 display 되기 바로 전에
그 시점의 필요한 정보들을 가지고 해당메뉴의 상태를 설정한 뒤
사용자에게 보이도록 합니다. 따로 메뉴의 state등을 유지 관리해야할
필요는 없어보입니다.
현재 열려있는 브라우져 탭의 리스트가 메뉴에 나타나는 것도 위와 같이
화면에 보이기 바로 전에 그목록을 메뉴에 추가시켜서 보여주는 것입니다.
댓글 달기